Setup
Please follow the common Adyen instructions to get set up with SEPA. Next, make sure to enable SEPA as a payment method on your configured account.Usage
To create a SEPA payment, set themethod to sepa when calling the transaction API.
Recurring payments
SEPA via Adyen supports recurring payments. To process a recurring payment, please be aware of the following limitations when storing a SEPA payment method for future use.- To store a SEPA payment for future use, set
store: trueon the transaction request. - When stored, a SEPA payment method is initially in a
processingstate until a webhook is received from Adyen. You need to set up the AdyenRECURRING_CONTRACTwebhooks for this update to be received. - A stored SEPA payment method in a
processingstate can not be used in Embed until it is ready and marked assucceeded
- SEPA supports the
payment_sourceofrecurringandinstalment, which maps toSubscriptionon the Adyen API. In all other scenarios it sets the recurring processing mode asUnscheduledCardOnFile. - Until the first transaction is settled, a stored SEPA payment uses a different mandate for the subsequent request. In a production environment, this might lead to a subsequent payment failing if the original mandate has not been fully settled yet.
Auto-rescue
Adyen’s auto-rescue feature is supported by this connector. This feature will automatically retry customer-not-present direct debit transactions when they receive a chargeback. To enable this feature, pass in the following connection options for Adyen when making a subsequent payment request.Please note that this feature only works for customer-not-present transaction where
is_subsequent_payment is set to true.autoRescue- A boolean value that enables the feature. This defaults tofalse.maxDaysToRescue- The rescue window, in days. You can specify between 1 and 42 days. Adyen recommends using a rescue window of one calendar month (30 days).autoRescueScenario- This is one of the test scenarios as defined by Adyen. This only works in sandbox.ownerName- Set this to the type of chargeback that you want to simulate. Use a concatenation of chargeback and the reason code. For example,chargeback:MS03orchargeback:AM04. This only works in sandbox.
capture_succeeded in the system as the payment
is always processed successfully initially. Instead, the auto-rescue fights the chargeback by re-attempting the payment.
The system does not report on this attempts, but may report the chargeback in settlement reports.
Testing
In a test environment, you can simulate an SEPA payment. Adyen has extensive instructions on how to help with this.Integration
For the alternative payment methods the default integration for Adyen is through a redirect to a hosted payments page.Redirect integration
Start by creating a new transaction with the following required fields.POST /transactions
Please use "" for the value of the
<method>.payment_method.approval_url and the transaction will be in the
buyer_approval_pending state.
approval_url (open in a browser or Webview) so they can complete authentication and approve the payment.
After approval the buyer is redirected to the redirect_url you provided when creating the transaction.
Do not rely solely on the redirect — either poll the transaction or (recommended) rely on webhooks to detect the final status (for example capture_succeeded or failure states).
Direct integration
Adyen provides web, Android and iOS for a direct integration. For these flows you should indicate the platform by setting an appropriateintegration_client
when creating the transaction, and then build a client-side integration that uses the POST /transactions/:transaction_id/session API to initialize the Adyen SDK.
To start, create a new transaction with the appropriate integration_client.
Please use "" for the value of the
<method>.session_token which can be used to get the session data for that transaction.
sessionId and sessionData required to load the Adyen SDK.
Complete the transaction
Recommended On mobile integrations, after the buyer completes the payment flow, the Adyen SDK provides the developer with anonFinished call, which includes a statusCode.
The system automatically syncs the status through webhooks, but to complete the transaction it is also recommended sending a GET request to the default_completion_url
provided in the session response with the sessionId and the sessionResult as query parameters to finalize the transaction. This also moves the transaction
to a completed status without waiting for the webhook to be sent.
The call returns a 204 No Content response. After receiving this response, you can also optionally fetch the transaction to confirm final status.