One-time payment
Swirepay supports one-time charges (single capture for goods or services) in two complementary ways. Pick the model that fits how much checkout UI you want to build and how your backend orchestrates payment APIs.
Choose your integration model
| Direct integration | Hosted Payment Link | |
|---|---|---|
| Also known as | API-first / server-driven checkout | Payment Link / hosted checkout |
| Who collects card or ACH details | Your web or mobile app (then tokenized via Swirepay) | Swirepay’s hosted payment page |
| How payment credentials reach Swirepay | Your frontend calls POST /v1/token (publishable key); only token references go to your backend to create the payment method and charge — full PAN does not travel through your servers | Customers enter credentials only on the hosted link URL; your backend creates the link and uses GID / verify APIs (no hosted card entry in your UI) |
| Your backend builds | Token → customer → payment method → payment session | POST /v1/payment-link → redirect payer to link → optionally GET …/verify after return |
| Best when | Full control over UX, APIs, and reconciliation | Faster launch, minimal payment UI development |
Recurring charges
Both models start from similar primitives (customers, amounts, notifications). Recurring billing uses a setup session after the payment method exists — see Recurring payment.
Partner integrations (x-destination-account)
If you onboard submerchants under your platform, send the optional x-destination-account header (submerchant sp-account-id) on requests that operate in their context.
- Direct integration: token, customer, payment method, and payment session — see Partner integration.
- Hosted Payment Link: create, retrieve, and verify payment link calls — see Hosted Payment Link.
Where to read next
- Direct integration — token → customer → payment method → payment session (current detailed guide).
- Hosted Payment Link — create link, redirect, verify, callbacks.
API reference: Payment Link, Payment session, Token.