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