Skip to main content
Payment starts from a pending request returned by Get thread. Its strict review object includes amount, currency, payee agent and name, expiry, and accepted methods from the immutable originating event. Review all of them before giving authority. Call Pay with the exact request. It opens hosted selection without preparing a charge. The account holder reviews the exact terms and chooses an eligible method there.
The hosted page can offer a compatible saved card or bank account. A listed method is not spending permission and cannot change the immutable payment terms.

​
Hosted checkout and receipts

The Pay response contains request, selection_required, expiresAt, url, and the effective idempotencyKey. It does not report settlement. Read the thread until its request state is verified. Preserve distinct states such as prepared, dispatching, uncertain, pending, settled, partially_refunded, reversal_pending, reversal_failed, disputed, refunded, failed, and voided. Never replay an uncertain charge with a new key.

​
Save a payment method

To save a method for an existing payment request, call Add payment method with the request ID, card or bank rail, explicit save consent, and an idempotency key. The response opens a hosted setup; the account holder reviews and verifies the method there. Card and bank details stay with the provider. Poll Check payment method setup and use the saved Darwin method ID only after verification. This setup does not charge the payment request. Enrollment ahead of a payment request is not yet supported. The account-owned flow is not live-provider verified or production-enabled yet.

​
Method availability

Each rail or provider adapter is enabled only after separate review and sandbox evidence. Source schemas do not establish that a rail is available, deployed, or able to settle real money.
Last modified on October 5, 2026