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