Create a payment
Create a receive or send Payment, the canonical financial obligation for a money flow.
intent picks a business flow (receive or send), not a payer payment method. Idempotency-Key is required; reuse it only with the identical request. The response always uses a payment_* ID. paymentAmount names one asset and exactly one representation, decimal or atomic. Commercial fees, destination, settlement, the optional return URL and capability snapshots are frozen atomically with the Payment.
Receive creates an escrow-backed checkout. Payers then use Direct crypto, cross-chain Routing or an enabled on-ramp method through the Public Checkout API. This create response is the only Partner API response that returns checkout.clientSecret: store it securely, or redirect with checkout.paymentUrl. A returnUrl must exactly match an app URL configured in Payment settings; hosted checkout appends only stableyard_payment_id and never treats the return as payment proof.
Send creates an outgoing execution and its required next action. Preview first and proceed only when the selected source is available.
- Crypto send supports direct transfers and enabled Arbitrum Vault routing through a deposit-address order. A required route is executable when the Vault funding option reports
vault_routing; Stableyard funds and verifies the route under the same Payment ID. Connected-wallet cross-chain send is unavailable. - External QR, one-time External Bank Transfer and verified Linked Bank Payout are executions of this same Payment; there is no standalone off-ramp API. Offer them only when
/v2/partners/configreports the method available. They verify the destination and resolve funding terms at create time instead of using preview; the US linked-bank route fixes crypto input without locking final USD delivery, and creating the Payment neither debits the Vault nor submits a duplicate payout. - For a linked bank, send only
bankAccountId. Stableyard resolves the provider references and creates one idempotent provider transaction before collection. - Personal or peer-to-peer QR codes are rejected before quotation with
details.reasonCode: personal_qr_not_supported; use External Bank Transfer instead. - A bank-lookup result marked
provider_state_uncertainis not retryable, because the external rail may already have created a pending transaction.
Authorizations
HTTP Basic auth. Username is the Stableyard app ID. Password is the app secret. The optional Stableyard-Version request header must match the environment pin.
Headers
Required retry key. Reuse only with the identical payment request.
"payment-request-001"
Optional contract-version assertion. Omit it to use the app environment's pinned version. A different supported version is accepted only after that environment is explicitly migrated.
2026-09-09 Body
- Receive payment
- Send payment
- External QR payment
- External bank payment
- Deliver an exact USD amount
- Collect an exact crypto amount
Create a bounded checkout that collects funds and settles them to a UPA or external wallet.
"receive"Choose where Stableyard ultimately settles the receive Payment. A UPA uses its settlement profile; an external wallet is paid directly without creating a UPA.
- UPA by account ID
- UPA by external user ID
- External wallet
Recommended for business integrations. For example, 10.00 USDC.
- Decimal amount
- Atomic amount
"collect_exact"Optional hosted-checkout return URL. It must exactly match an app URL configured in Payment settings.
20481 - 5001 - 25660 <= x <= 86400Response
Created payment
The exact action the caller must complete. Null means Stableyard needs no action from the partner right now.
- Action required
- Start account KYC
- Verify UPA email
- Complete hosted compliance
- Wait for partner KYC
- Contact support
- No provider action