Who is responsible
This service is run by its operator (ifinsta), who decides what is kept and why. The project that publishes the software receives nothing from anyone's payments: no copy, no feed, no telemetry. A payment on this service involves four parties: the payer, the business, the business's provider, and the operator of this service. This page is about the operator's part.
What a payment keeps, and no more
- The money: the amount and currency the server fixed, the business's own reference and description, and the final state with every attempt's history.
- The payer, in the least identifying form that still proves the payment: a phone number or an email address is stored masked or hashed; the payer needs no account, and this service keeps no payer profile. Any metadata attached to a payment is whatever the merchant sent, and the merchant says what it means.
- The proof: the provider's answer codes as reported, the receipt code the payer's page shows, and the webhook deliveries that told the merchant.
Everything above is attached to the payment. Nothing here builds a person's history across businesses.
How long anything is kept
Personal data on a finished payment — the masked or hashed identifiers, the receipt's address — is removed by a scheduled sweep one year after the payment finishes. What must stay for the money to be auditable stays: amounts, states, provider answers, and the day-closing records reconciliation uses. A data request that erases a subject takes the personal identifiers away and the financial record stays, on purpose.
Merchant and operator data
- A business record: the business's name and identity as ifinsta.com vouches for it, its markets, and its connections' lifecycle.
- Connection credentials: the business's own provider keys, sealed by the service's key store and never re-shown in full; the dashboard and back office show a hint only.
- Keys: minted and shown once, then stored as a hash with a visible prefix.
- Operator actions: every suspension, refund approval, data request and switch is written to the audit trail with the operator's name and, where it applies, a written reason.
What leaves the service
- To the business's provider: exactly the calls the connection needs to collect, confirm and query. Every provider origin is declared in its document, published as the egress allowlist, and the host refuses everything else.
- To ifinsta.com: the identity checks a sign-in needs, and nothing further.
- To the merchant's systems: the signed webhook deliveries to the endpoints the merchant registered.
No analytics packages, no third-party scripts, no adverts. Pages load themselves from this service alone, and the page policy only allows this service's own origins.
Getting a record found, exported or erased
Ask the business you paid, who can raise it with the operator, or ask the operator of this service directly. Requests are handled by an operator through a purpose-built tool: it looks up one exact phone number or email — no partial matches — finds the payments, and erases or exports the subject's data. Every request is answered within 30 days, is itself audit-logged with the operator's name, and is rate-limited to prevent fishing for who paid whom.
What we do not do
- No profiling, scoring or product analytics on payers.
- No card data of any kind — no number, no expiry, no code — which is also why the hosted page carries no card fields.
- No sharing with anyone other than the three parties above, except where the law requires the operator to.
Questions about any of this: contact, and vulnerabilities through the security policy.