includeThreadState=true. Messages and pending requests are in threads[].state. Keep the actRequestId returned when starting work.
Payment starts from a pending request returned by Get Act request. 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 Act with the thread ID and a payment_response containing the exact requestId. It opens hosted selection without preparing
a charge. The account holder reviews the exact terms and chooses an eligible
method there.
Hosted checkout and receipts
Use anIdempotency-Key header for retries. The Act response’s typed result 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.If your client pays a provider directly
Search does not declare every provider’s payment rails or payment account requirements. Do not present a universal supported-method list from Search metadata. Obtain the current methods and exact charge terms from the provider’s verified flow, then show the payee, amount, currency, expiry, and method to the person before authorization. Keep payment details in the provider’s secure checkout or your own compliant payment integration, not inconnectionPrompt or chat. Darwin’s payment_response, hosted URL, and saved method IDs apply only to a Darwin Act request. An opened checkout or accepted API call is not a settled payment. See Use Search results.