Payment-method icon

Wero for API only

Add Wero to your API-only integration.

You can add Wero to your existing integration. The following instructions show only what you must add to your integration specifically for Wero.

If an instruction on this page corresponds with a step in the main integration guide, it includes a link to corresponding step of the main integration guide.

Requirements

Requirement Description
Integration type Make sure that you have an existing API-only integration.
Redirect handling Make sure that your existing integration is set up to handle the redirect.
action.type: redirect.
Setup steps Before you begin, add Wero in your Customer Area.

How it works

  1. The shopper selects Wero as the payment method.
  2. The shopper enters their details in the payment form that you build, if applicable.
  3. When you make the payment request, you include additional information about the items that the shopper intends to purchase.
  4. Your existing integration setup will handle the redirect.

Build your payment form

Include Wero in the list of available payment methods. You do not need to collect any additional information from the shopper in your payment form.

You can download the logo for Wero to use in your form.

Get Wero as an available payment method

When you make the /paymentMethods to get available payment methods, specify the following so that Wero is included in the response.

Parameter Values
countryCode BE, DE, FR, NL
amount.currency EUR

Add additional parameters to your /payments request

You do not need to add any parameters when you make a payment.

Handle the redirect

  1. To complete the payment, redirect the shopper to the action.url returned in the /payments response, taking into account the following recommendations:

    • When using the HTTP GET method:
      For security reasons, when showing the redirect in the app, we recommend that you use SFSafariViewController for iOS or Chrome Custom Tabs for Android, instead of WebView objects. Also refer to the security best practices for WebView.

    • Redirection for mobile integrations:
      For mobile integrations, we strongly recommended that you redirect the shopper to the default browser of their device. Redirecting to the default browser ensures the best compatibility, handling of multi-factor authentication, app-to-app redirection, and error handling.

  2. After the shopper is redirected back to your website, check the payment result by making a POST /payments/details request, specifying:

    • details: object that contains the URL-decoded redirectResult returned when the shopper was redirected back to your site.

  3. In the response note the following:

    • resultCode: use this to present the result to your shopper.
    • pspReference: our unique identifier for the transaction.

Present the payment result

Use the resultCode that you received in the /payments/details response to present the payment result to your shopper, or wait for a webhook to know the outcome of the payment.

The resultCode values you can receive for IRIS payments are:

resultCode Description Action to take
Authorised The shopper completed their payment, and it has been sent to the bank for processing. In most cases, this means that you will receive the funds. Inform the shopper that the payment has been successful.
Cancelled The shopper cancelled the payment while on their bank's website. Ask the shopper whether they want to continue with the order, or ask them to select a different payment method.
Error There was an error when the payment was being processed. Inform the shopper that there was an error processing their payment. The response contains a refusalReason, indicating the cause of the error.
Pending or Received The shopper has completed the payment but the final result is not yet known. Inform the shopper that you have received their order, and are waiting for the payment to be completed.
You will receive the final result of the payment in an AUTHORISATION webhook.
Refused The payment was refused by the shopper's bank. Ask the shopper to try the payment again using a different payment method.

Adyen also sends you webhooks, if you signed up for them. Webhooks indicate the status of the payment.

eventCode success Action to take
OFFER_CLOSED true Release inventory; show "session/payment expired or cancelled", and offer a retry with new reference.
AUTHORISATION true Fulfil order.
AUTHORISATION false Show payment was declined and offer a retry.
REFUND true Confirm refund to consumer.
REFUND_FAILED true Investigate, retry or compensate via alternative means.
CAPTURE_FAILED true Retry the payment.

Test and go live

Your checkout page always redirects you to a test payment page where you can simulate different Wero result codes.

  • AUTHORIZED : Successful payment
  • REFUSED : Refused payment
  • CANCELLED : Cancelled payment
  • ERROR : Technical failure
  • RECEIVED: Payment still in progress. Retry the /payments/details request.

It is currently not possible to simulate the RECEIVED and ERROR statuses on the test environment. These are rare result codes that your systems should be ready to handle.

The test payment page redirects you back to your checkout page after selecting a result code.

Production Smoke Test

After enabling Wero in production, run this minimum verification before announcing go-live:

  1. Place a real payment of €0.01 from a Wero enabled German, Belgian, French, or Dutch bank account.
  2. Confirm AUTHORISATION webhook received with success: true.
  3. Confirm payment appears in CA with the correct amount and state.
  4. Wait for settlement to happen.
  5. Issue a full refund via /refunds.
  6. Confirm REFUND webhook received with success: true.
  7. Verify the refund appears in the consumer's Wero app within 1-10 minutes.

The pass criteria for a smoke test are: complete all 7 steps without error in the live environment.

See also