Requests a cancel. Accepts the bare pspReference: no money facts are needed.
Requests a capture. Adyen answers { status: "received" }, so the reported
status is "processing" and no amountCaptured is invented — the settled amount
is knowable only from the CAPTURE webhook.
Tokenize-first completion. clientToken is the JSON the client adapter's
confirm() produced:
paymentMethod blob from Adyen's hosted card fields, which
creates the payment (POST /payments), or{ details, paymentData } from a resolved action, which finishes it
(POST /payments/details).The signed context is the only trusted source of amount/currency/capture
method. An action in the response surfaces as requires_action with the
action preserved on raw; a refusal is raised as a mapped PayFanoutError
rather than folded into a "failed" PaymentInfo.
Creates NO Adyen object: the payment only exists once completePayment
posts /payments. Amount, currency, reference, capture method and the
checkout fields are signed into the returned pspSessionId, which is also
the session's clientSecret — the browser reads the payload half to drive
Adyen Web's own copy and cannot tamper with the amount.
Throws PayFanoutError (code "invalid_request") on unparseable payloads; maps genuinely unknown-but-valid event types to type "unknown" rather than throwing.
Requests a refund. Always "pending": Adyen acknowledges the request and the REFUND / REFUND_FAILED webhook carries the outcome. With no payment read, an amountless (full) refund takes its value from the composite pspPaymentId.
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).
Adyen is a PUSH-ONLY provider: its
pspReferenceis a write target, there is no read for a payment or a refund, and every modification answers with a bare acknowledgement whose outcome arrives by webhook. Two consequences shape this adapter:supportsPaymentRetrieval: false,supportsRefundRetrieval: falseandmodificationOutcome: "asynchronous"; capture and cancel resolve "processing" and refunds "pending", never a terminal state Adyen has not confirmed.PaymentInfo.pspPaymentIdis the composite"{pspReference}:{value}:{currency}". A capture or refund needs the payment's currency (and, when no amount is given, its value); with no read and no persistence, the money facts ride the reference. The part before the first ":" is Adyen's own pspReference — the one webhooks report — and cancels accept it bare.