Voids the remaining authorization. This also works AFTER partial settlements (multi-capture flows) — settled funds stay settled and the returned PaymentInfo reports them (status "succeeded"), derived from the pre-void remainder; only a payment with no settlements at all comes back "canceled". Caller-keyed settlements are not rediscoverable statelessly, so LATER retrievePayment calls lose that split once the void has consumed availableToSettle (documented limitation).
Only present if getCapabilities().supportsManualCapture. Capture is the canonical double-charge operation — the idempotency key is REQUIRED, and under supportsMultiCapture each partial capture is its own charge with its own key.
Merchant-initiated charge of a MULTI_USE token. storedCredential carries the networks' credential-on-file semantics (INITIAL while the customer is present, SUBSEQUENT for recurring; ADHOC covers unscheduled top-ups).
Tokenize-first completion (§4a): create the actual Payment from the client's Payment Handle token.
Reality check: POST /payments strictly rejects
webhook/returnLinks fields (error 5023 "field not recognized") — those
belong on the payment HANDLE. Webhook endpoints are configured in the
Paysafe portal; webhookUrl/returnUrl stay in the session context for
handle-level flows (redirect methods) and future API support.
Creates the PSP-side customer that saved instruments attach to.
Creates a subscription the scheduler bills itself, against an
already-vaulted MULTI_USE token (savePaymentMethod's output — a
single-use Paysafe.js token is rejected by the scheduler). Subscriptions
attach to a PLAN: pass planId to bill from a host-managed plan (the
input amount/currency/cadence must match it — the adapter verifies and
rejects a mismatch rather than silently billing something else), or omit
it and the adapter creates a dedicated open-ended plan
(numberOfCycles 0 = infinite) from the input inline.
Idempotency: merchantRefNum is the scheduler's dedupe field ("unique
for this accountId") and doubles as the lookup key, so input.merchantRefNum
wins when supplied — passing it transfers the idempotency duty to it —
and idempotencyKey fills it otherwise. A replayed create recovers the
existing subscription by that refNum instead of failing. The inline PLAN
has no refNum channel, so a transport-retried creation can leave an
orphan plan behind; the subscription itself stays exactly-once, so no
double billing can result.
pspCustomerId and metadata have no scheduler channel and are
withheld: the customer profile derives from the vaulted token, and the
subscription object carries no metadata field.
No PSP call happens here: Paysafe.js tokenizes client-side first. The "session" is a signed, self-contained context (amount, currency, merchant account, webhookUrl, ...) that completePayment later verifies and trusts. Paysafe's per-session webhook registration requirement is honored by carrying webhookUrl in this context into the /payments request.
Deletion needs the handle's internal id; hosts only hold the token — resolved here.
Pages the Payment Scheduler's subscriptions as unified records. The scheduler paginates by offset (limit default 10, max 50); the opaque cursor is the next offset. A full page always yields a nextCursor — the follow-up page comes back empty with none — because the spec does not pin whether meta.numberOfRecords counts the total or the page, and a wrong guess would either drop records or never terminate.
Optionalinput: ListNativeSubscriptionsInputThrows PayFanoutError (code "invalid_request") on unparseable payloads; maps genuinely unknown-but-valid event types to type "unknown" rather than throwing.
Paysafe refunds settle against a settlement, not the payment — resolved here so callers keep one API.
GET /subscriptions/{id}. Paysafe keys by id alone — savedPaymentMethodToken is not needed.
Only present if getCapabilities().supportsPaymentRetrieval. Push-only PSPs expose no read for a single payment — their hosts follow payment state through webhook deliveries instead.
Polls an async refund to a terminal state — sandbox refunds in particular sit PENDING until the overnight settlement batch runs.
Converts the client's SINGLE_USE handle (from Paysafe.js tokenize) into a permanent MULTI_USE token under the customer. This is the tokenize-first counterpart of Stripe's save-during-checkout.
Stateless session update: verify + merge + re-sign. Paysafe has no PSP object yet (tokenize-first), so the "update" re-issues the signed context with the changes and a fresh TTL. The returned session carries a NEW pspSessionId/clientSecret — the old token keeps its own (original) expiry, so hosts should hand the new one to the client promptly.
"Test connection" probe: one side-effect-free read against the Customer
Vault — look up an all-but-certainly-absent profile. This endpoint is an
object-or-404 point lookup, so authentication is settled BEFORE the resource
is resolved: only 401/403 means bad credentials, while every other status —
a 2xx match, the expected 404 "no such profile", or any business 4xx —
proves the credentials authenticated. Classified so a host UI can tell a
wrong key (auth) from a transient outage (network). It is a single call,
never retried (an auth rejection must not be replayed), and the credentials
never leak into the result.
Zero-amount verification via Paysafe's Verifications API — no charge, nothing stored.
Webhook handling — same adapter, separate concerns. Both async: future PSPs may need remote key retrieval; the contract stays uniform. MUST operate on the RAW request body bytes/string — re-serializing a parsed body breaks signatures (the conformance suite tests this).
PATCH /subscriptions/{id} to CANCELLED — the FINAL status ("cannot be re-activated"); SUSPENDED is the reversible pause and is deliberately not used here. Verified-idempotent: the scheduler does not document patching an already-terminal subscription, so on any rejection the adapter re-fetches and treats CANCELLED/COMPLETED as success — billing that is already stopped can never fail a replayed cancel. The PATCH carries no merchantRefNum (the scheduler has none there); replay safety comes from CANCELLED being absorbing plus that re-fetch, which is why the required idempotencyKey has no wire mapping on this call.