Reference · built on requestConnectorPayments, billing & fraud

Adyen

Payment events, refunds, chargebacks, payouts, and reports from Adyen through the Checkout API and Standard webhooks.

Request accessPricing ↗

About

Adyen is a payment processor for online, in-person, and platform payments. A merchant account holds authorisations, captures, refunds, chargebacks, and payouts, and Adyen pushes each state change to your endpoint as a Standard webhook event such as AUTHORISATION, CAPTURE, REFUND, or NOTIFICATION_OF_CHARGEBACK.

Through Fibric, an operator reads those events and the payment record behind them, then proposes the next step: capture an authorisation, issue a partial refund, or defend a chargeback with documents. You approve. The connector calls the Checkout API or Disputes API once and leaves a receipt: what changed, why, and how to undo it.

This is a reference listing. It documents what Fibric would read from Adyen and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • AUTHORISATION, CAPTURE, CAPTURE_FAILED, CANCELLATION, and EXPIRE events on the Standard webhook, each carrying the pspReference of the payment
  • REFUND, REFUND_FAILED, and REFUNDED_REVERSED events, which carry the asynchronous outcome of a refund request
  • Dispute events: NOTIFICATION_OF_CHARGEBACK, CHARGEBACK, CHARGEBACK_REVERSED, SECOND_CHARGEBACK, REQUEST_FOR_INFORMATION, and DISPUTE_DEFENSE_PERIOD_ENDED
  • Payout events PAYOUT_THIRDPARTY, PAYOUT_DECLINE, PAYOUT_EXPIRE, and PAIDOUT_REVERSED
  • REPORT_AVAILABLE events announcing newly available reports
  • Applicable defense reasons and document requirements for a dispute from /retrieveApplicableDefenseReasons

Proposed actions

  • Target capability: propose a capture of an authorised payment through POST /payments/{paymentPspReference}/captures
  • Target capability: propose a full or partial refund through POST /payments/{paymentPspReference}/refunds, within the captured amount
  • Target capability: propose cancelling an uncaptured authorisation through /payments/{paymentPspReference}/cancels or /reversals
  • Target capability: propose defending a chargeback: upload documents with /supplyDefenseDocument, then submit with /defendDispute
  • Target capability: propose accepting a chargeback through /acceptDispute when a defence is not worth pursuing

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Defend a chargeback before the window closes

    NOTIFICATION_OF_CHARGEBACK opens the defense period. The operator pulls the applicable defense reasons, gathers order and delivery records, and proposes a document set. You approve. The connector supplies the documents and calls /defendDispute once.

    With Chargeback Evidence

  • Reconcile payouts against reports

    REPORT_AVAILABLE announces a new report. The operator matches payout lines to captures and refunds in your ledger and flags lines that do not tie out.

    With Payout Reconciliation

  • Refund within the remaining balance

    A support agent asks for a refund. The operator checks the captured amount and prior partial refunds, then proposes a refund within the remaining balance for approval.

    With Refund Policy, Concession Review

  • Release a held authorisation

    When an order is cancelled before shipment, the operator proposes a cancel or reversal of the uncaptured authorisation rather than a refund.

    With Cancellation Window

Requirements

  • An Adyen merchant account with access to the Customer Area
  • An API credential with at least one enabled role, including the API dispute management role for Disputes API calls
  • A Standard webhook configured in the Customer Area pointing at an HTTPS endpoint, with dispute events enabled
  • Your company's URL prefix, since Checkout API calls on the live environment go to {PREFIX}-checkout-live.adyenpayments.com
  • A new API key generated in the Customer Area of the live environment when moving out of test
Authentication
An API credential created in the Customer Area, sent as the X-API-Key header, with roles enabled for each API the connector calls.

Limits

  • Refunds are asynchronous. The API accepts the request; the outcome arrives later as a REFUND or REFUND_FAILED webhook.
  • Funds from a refund can take up to 40 business days to reach the shopper, depending on the payment method.
  • The sum of multiple partial refunds cannot exceed the captured amount.
  • Dispute defense documents must meet format and size rules: JPG and TIFF up to 10 MB, PDF up to 2 MB.

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Adyen ↗

Questions and answers

Does Adyen tell you when a refund fails?
Yes. Refunds are asynchronous. The Standard webhook sends REFUND with success true or false after validation, then REFUND_FAILED if the refund is rejected later, for example when the requested amount is too high. REFUNDED_REVERSED reports funds returned to your account.
What does the connector need to work with disputes?
An API credential with the API dispute management role, and a Standard webhook with dispute events enabled. Dispute PSP references arrive in NOTIFICATION_OF_CHARGEBACK and related events; the Disputes API then handles defense reasons, document upload, defend, and accept.
Which Adyen APIs does this listing use?
The Checkout API for captures, refunds, cancels, and reversals; the Disputes API for defend and accept; and the Standard webhook for payment, dispute, payout, and report events. The Balance Platform, Transfers, and Terminal APIs are outside this listing.
Ask about Adyen

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Adyen through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy