Security

Each account is bound to a single active device. Signing in from a new device starts a takeover flow that must be approved from the device you already trust, or completed through account recovery. This prevents an attacker who obtains a password from silently gaining a parallel session.

Registration, sign-in and recovery are protected by email verification and one-time codes. Codes are short lived, single use and bound to the request that created them. We never ask you for a code, and no member of staff can read one.

Sensitive changes, including device takeover and account recovery, apply a time-limited hold on outbound activity. The hold and its expiry are displayed in the product rather than presented as an unexplained failure. Inbound activity and account visibility are unaffected.

The interface hides what you cannot do; the platform decides what you may do. Every request is authorised on the server against your session, your verification state and the permissions attached to your role. A screen that renders an action is never the thing that grants it.

Business accounts support approval controls, so that an instruction above a configured threshold requires a second authorised user before submission.

Every financial request carries an idempotency key generated once for a user intent and reused on retry, so that a repeated submission cannot create a duplicate payment. Amounts are held as integer minor units with an ISO 4217 currency code and are never computed in the browser. Instruction state changes are recorded in an append-only history with timestamps and references.

Traffic between your device and the platform is encrypted in transit using current TLS. Data at rest is encrypted. Access to production data follows least privilege, is granted for a defined purpose, is time bound where possible, and is logged. Administrative actions are recorded in an append-only audit log.

Sensitive instrument data is not held by the interface. Full card numbers, security codes, full external account identifiers, verification document images and one-time codes are never displayed or stored by the customer application.

API keys, provider credentials, signing keys and webhook secrets are held in dedicated secret storage. They are never placed in application code, in files delivered to the browser, in browser storage, or in a query string. Credentials issued to a business are displayed once at creation and can be revoked immediately.

The platform is monitored for availability, error rate and anomalous behaviour. Payment processing is designed so that an interrupted operation resolves to a definite state rather than an ambiguous one, and unresolved items are placed in a controlled recovery queue for operator attention rather than being retried blindly.

Error messages are deterministic and carry a copyable reference. They never expose internal systems, partner identities, stack traces or database errors. If you contact us about a failure, quoting that reference lets us locate the exact event.

If you believe you have found a security vulnerability, report it through the support route with enough detail to reproduce it. Do not test against accounts that are not your own, do not attempt to access another customer data, and do not run tests that degrade the service. We acknowledge reports and keep the reporter informed of the outcome.

Use a unique password, keep your bound device updated and locked, and never share a one-time code. Check the recipient details at the review step before confirming an instruction, because a confirmed instruction may not be recallable. Report anything unexpected promptly.