Security

Protections you can check, and honest limits.

This page lists what is built in and can be verified, not adjectives. Where the work is yours — your keys, your provider contract — the page says so.

In transit

  • Terminating TLS is the host's edge proxy, which adds HSTS and refuses plain HTTP; pages are served only over the encrypted hop.
  • Every page carries a strict content-security policy: no third-party script, no inline style or script, only this service's own origins.
  • Provider callbacks are host-routed and each connector document names how they are verified; nothing is trusted for arriving, only for its verified content.

Keys and secrets

  • The engine's master key comes from the environment at start-up, and the configuration refuses development defaults outside development hosts.
  • Connection credentials and webhook secrets are sealed with the service's encrypting key store, unpacked only at the last moment of a call; the dashboard, the back office and pages show a hint, never the value.
  • API keys are shown once at minting and stored hashed; revoking one ends it at once.
  • No secret is ever accepted in a URL. URLs carrying values like that are refused by the edge, so nothing lands in a log.

Who can move money, and when

  • Merchant sign-in is delegated to ifinsta.com's identity service: pay keeps its own short sessions and no passwords.
  • Step-up verification is required where real money moves, and test and live money are the same objects in different modes, separated by the key's mode on every call.
  • The back office is separate from the merchant dashboard, with its own access, its own audit trail, and kill switches that pause a whole market without touching anyone's data.

The money path

  • The engine only orchestrates: it cannot hold, pool or pay out. A schema guard refuses any table that would, and the refusal is a test that runs with every build.
  • At most one attempt may succeed per checkout, and the states checkouts, attempts and refunds may move through are published in the contract.
  • Egress is an allowlist rendered from the provider documents, calls leave from fixed published addresses, and a provisioning script proves direct egress is refused.

What we ask of you

  • Guard your secret keys like the money-moving credentials they are; a leaked key is revoked in one step on the dashboard, and should be.
  • Register webhook endpoints over HTTPS, verify the signature, and keep your clock within the 300-second replay bound.
  • Connect only providers whose terms you can meet; their pricing and their contract with you are not this service's.

What we do not claim

  • No certification is claimed on this page. Where the engine's pages never ask for a card and carry no card fields, that is a scoping statement, not a badge.
  • The penetration-test scope for new public surfaces, the drills that rehearse failures, and the runbooks behind every alert are in the repository, not in marketing copy.
  • Deleting what a provider keeps, or revoking what their systems remember, sits with the provider and your contract with them.

Report a vulnerability

Privately, through the security policy — never in a public issue. What counts as in scope, and how a report is handled, is written down:

Read the security policy →