Interface AdapterCapabilities

Whether capture/cancel/refund outcomes are known when the call returns. "asynchronous" providers acknowledge the request and deliver the outcome by webhook, so cancelPayment reports "processing" rather than a confirmed "canceled" — an adapter never claims a terminal state it has not confirmed.

Which PSP-native subscription operations the adapter implements — see NativeSubscriptionCapabilities. Honesty is per operation; declare only what the provider's own billing product supports.

True if the PSP flow is client-tokenize-first and the server must finalize the payment via completePayment (Paysafe: true, Stripe: false).

Hard PSP currency constraints (ISO 4217, uppercase). ABSENT means unrestricted. When present, the router pre-screens candidates by it — without it, a PSP-local currency rejection (invalid_request) aborts the failover cascade before an eligible PSP is tried. An adapter whose PSP takes too many currencies to list declares the few it refuses in unsupportedCurrencies instead, or declares both.

fetchEvents() is available for missed-webhook reconciliation.

listPayments()/listRefunds() reconciliation passthroughs are available.

Authorize now, capture later.

More than one partial capture against a single authorization (each with its own idempotency key). Single-capture PSPs settle once and release the rest.

Zero/low-amount validation, no charge, no storage.

The PSP exposes a read for a single payment (retrievePayment). False is the push-only declaration — the payment reference is a write target only, and hosts learn payment state from webhooks alone, with no retrieve round-trip to reconcile against.

retrieveRefund is available, so an async refund (status "pending") can be polled to a terminal state. False means refund outcomes arrive only by webhook — requires supportsRefunds.

PSP-side vaulting: cards are stored by the PSP ONLY (SAQ-A unchanged), PayFanout and the host handle nothing but opaque tokens. When true, the adapter implements the customer/saved-method surface and off-session charging (the foundation of recurring payments / subscriptions).

updatePaymentSession is available (amount/metadata amendments after creation). NOTE: some PSPs re-issue the session — always use the returned PaymentSession's pspSessionId/clientSecret after an update.

Currencies the adapter refuses to send any amount in (ISO 4217, uppercase). ABSENT or empty means none. A PSP that takes most currencies cannot be given a supportedCurrencies list without refusing some it takes, yet its adapter may still refuse a few, such as a currency the PSP prices with another exponent than ISO 4217. An adapter may declare either list or both; a session's currency must pass each one declared.

Only session creation is screened: the router skips the adapter for a session in one of these currencies instead of aborting the failover cascade on its local invalid_request, and PaymentService refuses such a session with a non-retryable unsupported_operation. Session updates, saved-method charges and native subscriptions still meet the adapter's own refusal, so keep the local check: hosts can also call an adapter without PaymentService.

Declare a currency when the adapter refuses every amount it would send in it. The declaration is a trade-off: screening also refuses zero-amount sessions in the currency, even ones the adapter itself still serves because they send no amount, and the adapter's changeset must say so. A refusal of only some non-zero amounts (a whole-unit rule) stays a local check. Listed codes are compared trimmed and uppercased.

What verifyWebhookSignature can prove about a delivery — see WebhookSignatureScope. The conformance suite asserts a re-serialized body is rejected only under "raw-bytes"; a "field-values" provider signs values that survive re-encoding, so that assertion is unprovable without inventing a byte-level heuristic that would reject legitimate deliveries.