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).
OptionalsupportedHard 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.
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.
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.
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.