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.
Tokenize-first completion: create the payment from the browser's
hostedTokenizationId. The signed context is the only trusted source of
amount/currency/capture-method. A REDIRECT merchantAction (3-D Secure
challenge) surfaces as requires_action with the redirect URL on raw; the
customer completes it and the host reconciles with retrievePayment.
Creates the Hosted Tokenization session (POST /hostedtokenizations — no amount at this step) and encodes amount/currency/capture-method and the returned hostedTokenizationId into a signed, self-contained context that completePayment later verifies and trusts. The client mounts the iframe from the returned hostedTokenizationUrl (the session's clientSecret).
Throws PayFanoutError (code "invalid_request") on unparseable payloads; maps genuinely unknown-but-valid event types to type "unknown" rather than throwing.
Only present if getCapabilities().supportsPaymentRetrieval. Push-only PSPs expose no read for a single payment — their hosts follow payment state through webhook deliveries instead.
OptionalpayfanoutId: stringPolls a refund. Worldline Direct exposes no refund-by-id endpoint (that is
a Connect-era surface) — the only read is GET /payments/{id}/refunds — so
refundId is the composite "{paymentId}:{refundId}" that refundPayment
returned, resolved here through the payment's refund list.
"Test connection" probe: one side-effect-free read against the account's test-connection service. Authentication is settled before the resource is resolved, so only 401/403 means bad credentials; any other status proves the credentials authenticated. A single call, never retried.
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).
Resolves "canceled" only when the PSP confirms it. Under getCapabilities().modificationOutcome "asynchronous" the PSP merely acknowledges the request and the outcome arrives by webhook, so the returned status is "processing" — never an unconfirmed terminal state.