European Payment Methods
Netvalve supports a family of popular European alternative payment methods (APMs): iDEAL, Wero, Swish, EPS, TWINT, Bancontact, and BLIK. They all share the same redirect-based flow — the customer is sent to their bank or payment app to authorise the payment and then returned to your site.
You can offer them through the Netvalve Hosted Payment Page or the Checkout SDK. This page covers the shared flow and requirements; each method has its own short guide with a ready-to-use request example.
Available methods
Each method serves customers in specific countries and settles in a single currency. The order currency must match the method's currency, otherwise the method is not offered to the customer.
| Method | Customer country | Currency | paymentOption | Guide |
|---|---|---|---|---|
| iDEAL | Netherlands | EUR | apm_ideal | iDEAL |
| Wero | Germany, Belgium, France | EUR | apm_wero | Wero |
| Swish | Sweden | SEK | apm_swish | Swish |
| EPS | Austria | EUR | apm_eps | EPS |
| TWINT | Switzerland | CHF | apm_twint | TWINT |
| Bancontact | Belgium | EUR | apm_bancontact | Bancontact |
| BLIK | Poland | PLN | apm_blik | BLIK |
The customer only sees a method when the order currency matches. For example, a PLN order can offer BLIK; a EUR order cannot. Send the customer's country in customerCountryCode so the payment is created against the right locale.
How to offer a European APM
Contact the Netvalve team to enable the method on your account before going live. Netvalve provisions the method with the provider and configures your Hosted Payment Page layout.
High-level flow
These methods use the standard Netvalve redirect flow. Refer to the Hosted Payment Page guide for the full flow diagram.
- Create the order — your server posts the order with the method's
paymentOptionand the matching currency. - Redirect the customer — Netvalve returns a
redirectUrl; send the customer there. - Customer authorises — the customer is taken to their bank or payment app to approve.
- Handle the outcome — Netvalve returns the customer to your
successUrl/cancelUrl/failedUrl/pendingUrl. - Receive a webhook — Netvalve notifies your server when the final status is known.
Using the Checkout SDK
If you integrate with the Checkout SDK, the method renders automatically once it is enabled on your site — you do not select it in code. For an APM-first checkout that opens directly on the method, pass paymentOption (for example apm_ideal) when you create the session. The SDK handles the provider redirect and status polling for you.
Testing in sandbox
In the sandbox environment, Netvalve routes these methods to the payment method's own test system, so you get the complete end-to-end experience — the redirect, the real bank or wallet test screen, and the return to your site. No funds move.
Before you start
- Point your requests at the Sandbox / UAT base URL and use your sandbox credentials — see Environments.
- Ask the Netvalve team to enable the method on your sandbox site. A method that is not enabled is never offered, even with a valid
paymentOption. - Send the currency the method settles in (see Available methods). A
EURorder will not offer BLIK. - Use URLs the browser can actually reach for
successUrl/cancelUrl/failedUrl/pendingUrl, and a publicly reachable HTTPS endpoint for your webhook — the final status usually arrives there rather than on the return redirect. - Keep test amounts small (under about €5 or the local equivalent) and do not run automated load or stress tests. These are shared test systems provided by the banks and wallets.
Test data per method
Create the order exactly as you would in production, then follow the redirectUrl and use the values below on the test page you land on.
| Method | What to do on the test page |
|---|---|
| iDEAL | Select any bank from the list, or submit the bank code TESTNL2A. The test bank page then lets you pick the outcome. |
| Wero | Select Pay with Wero code and click the displayed code to copy it. Open the Wero sandbox consent page, click Give consent, paste the code, and choose Approve or Deny. |
| EPS | Select bank PSA BANK GROUP and log in with the test credentials — request them from the Netvalve team — then complete the TAN step (see EPS). Logging in alone does not complete the payment. |
| Bancontact | Use a test card: 60600599999899023 (expiry 01/2035) authenticates successfully, 60600599999899080 (expiry 01/2035) is denied. |
| BLIK | Enter any 6-digit code — for example 999009 — to simulate a successful payment. |
| Swish | No shared test credentials. Swish sandbox testing needs test apps and test accounts; request access from the Netvalve team. |
| TWINT | No shared test credentials. Request sandbox test credentials from the Netvalve team. |
Only some methods let you choose the outcome on the test page (iDEAL, Wero, Bancontact). For the others, treat the failure paths as webhook-driven: cancel or abandon the payment on the test page and verify your cancelUrl / failedUrl handling and the resulting webhook, then confirm the status independently with an Inquiry.
These payments complete asynchronously. Before going live, verify that your integration handles a PENDING (GTW_1002) result — the customer is returned to your pendingUrl and the final status arrives by webhook.
Verifying a payment
If your server does not receive a redirect or you need to independently confirm a status, use the Inquiry API. If the status is PENDING (GTW_1002), wait briefly and re-poll.
{
"traceID": "965c2c75-b29d-41fc-aa3a-6d40b9f3fbb0",
"responseTimestamp": "2024-04-25T13:48:49.959+00:00",
"transactionID": 22,
"responseCode": "GTW_1002",
"responseMessage": "Transaction status is Pending.",
"responseCodeType": "PENDING"
}
Related resources
| Resource | Link |
|---|---|
| Hosted Payment Page guide | Hosted Payment Page |
| Checkout SDK guide | Checkout SDK |
| Swagger API reference | API Reference |
| Webhook Message guide | Webhook Message |
| Error Codes reference | Error Codes |