Wero is a pan-European digital wallet initiative developed by EPI (European Payments Initiative), designed to provide a unified, secure and instant payment experience across participating EU countries. Built on SEPA Instant Credit Transfer (SCT Inst) rails, Wero aims to be a direct competitor to other mobile wallets and promote cross-border, real-time payments in the euro area.
With a focus on both online and in-store use cases, Wero allows users to send and receive money instantly enhancing convenience while maintaining compliance with European regulatory standards.
Get started
-
Contact NEXI Helpdesk to activate Wero payment method for your merchant profile.
-
Integrate by choosing the integration option tailored to your needs.
Integration options
NEXI Paygate supports Wero payments through the following integration types:
-
Hosted Payment Page: Initiate Hosted Payment Page by calling Create checkout session.
-
Hosted forms: Initiate Hosted forms by calling Create payment with:
"paymentMethods": { "type": "WERO", "integrationType": "HOSTED" }
Notice: For Wero with captureMethod.type=MANUAL the initial payment request translates to an event dependent payment plan.
Reverse payment
If a payment needs to be voided before settlement, you can initiate a reversal using the Reverse payment endpoint. Only unsettled Wero payments can be reversed.
Capture payment
If the payment was initiated with a manual capture flow (captureMethod.type=MANUAL), you must explicitly capture the authorized amount using the Capture payment endpoint.
If the initial transaction did not include the MANUAL capture method, the payment will be auto-captured by default.
Wero Transaction Statuses
The meaning of a transaction status depends on the Wero payment flow being used. Merchants should interpret the returned status according to the endpoint and transaction type.
1. Single Immediate Payment
A Wero Single Immediate Payment is processed as a single-step payment from the merchant's perspective.
Internally, the transaction consists of the following processing steps:
-
Consent approval followed by payment authorization
-
Automatic capture initiated by Paygate
The merchant submits a single payment request and receives only the result of the WERO authorization.
If the authorization is granted, Paygate automatically performs the capture on behalf of the merchant. The merchant can Inquiry the payment to retrieve the final status of the Settlement.
Merchant-facing statuses
|
Status |
Description |
Final |
|
AUTHORIZED |
The payment authorization has been successfully completed. Paygate will then automatically be completing the capture and settlement process on behalf of the merchant. |
Yes |
|
FAILED |
The payment authorization failed and the payment cannot proceed. |
Yes* |
Important
For Single Immediate Payments, the AUTHORIZED status confirms only that the payment has been successfully authorized. It does not indicate that settlement has already been completed.
Settlement is handled transparently by Paygate through the automatic capture process. The merchant never receives capture-related statuses such as CAPTURE_REQUEST or the final settlement result, but they can always Inquire via API the latest status.
Automatic capture processing
Whenever the authorization is successful (AUTHORIZED), Paygate automatically submits the capture request to EPI for settling the payment.
The automatic capture process is internal to Paygate and is not exposed through the merchant-facing API.
Intermediate capture processing states (for example CAPTURE_REQUEST) are internal Paygate statuses and are never returned to the merchant for Single Immediate Payments.
Automatic capture retry
In exceptional situations, the automatic capture may not be complete successfully on the first attempt due to temporary processing or settlement issues between the banks.
To maximize successful settlement of an already authorized payment, Paygate automatically retries the capture for up to seven consecutive days without requiring any merchant intervention.
This retry mechanism exists because the merchant receives only the authorization result and is not involved in the capture process.
If the payment still cannot be settled after the retry period, settlement is completed through a manual operational procedure agreed between the Acceptor Bank and the Consumer Bank in accordance with the applicable EPI operating rules.
The merchant must not submit an additional capture request for Single Immediate Payment, as capture management is performed exclusively by Paygate or Member Banks (case of Manual Settlement).
2. Event-dependent payment (manual capture)
An Event-dependent payment is processed as a two-step transaction:
-
Consent and authorization (same as Single Immediate)
-
Merchant-initiated capture
Once the business event defined by the merchant occurs (for example, shipment of goods or completion of a service), the merchant submits a capture request using the Capture API.
The default period allowed between authorization and capture for Wero event dependent payments is 7 days.
Authorization status
|
Status |
Description |
Final |
|
AUTHORIZED |
The payment has been successfully authorized and is waiting for a capture request from the merchant. |
Yes |
|
FAILED |
The authorization failed. |
Yes |
Capture status
After the merchant submits the capture request, the following statuses may be returned:
|
Status |
Description |
Final |
|
CAPTURE_REQUEST |
The capture request has been accepted and submitted to EPI or the consumer bank. Settlement is still pending. |
No |
|
OK |
The capture has been successfully settled over the SEPA Instant rails. |
Yes |
|
FAILED |
The capture could not be completed. |
Yes |
Under normal SEPA Instant processing conditions, the capture should reach a final status within approximately 10 seconds.
The merchant should periodically call the Inquiry API until either OK or FAILED is returned.
Unlike Single Immediate Payments, Event-dependent payments currently do not include an automatic capture retry mechanism. Support for automatic retries is being evaluated for a future release.
3. Refund
Refunds are initiated by the merchant through the dedicated Refund API.
After a refund request has been accepted, the following statuses may be returned:
|
Status |
Description |
Final |
|
CREDIT_REQUEST |
The refund request has been accepted and submitted to EPI or the consumer bank. Settlement is pending. |
No |
|
OK |
The refund has been successfully settled over the SEPA Instant rails. |
Yes |
|
FAILED |
The refund could not be completed. |
Yes |
Under normal SEPA Instant processing conditions, the refund should reach a final status within approximately 10 seconds.
The merchant should periodically call the Inquiry API until either OK or FAILED is returned.
4. Delayed settlement and inquiry
In exceptional situations, settlement between the acceptor bank and the consumer bank may take longer than the standard SEPA Instant processing time.
For capture and refund transactions that remain in a non-final state, Paygate automatically checks and update the transaction status according to the following schedule:
-
Approximately 1 minute after submission
-
Approximately 5 minutes after submission
-
Every 24 hours thereafter
These background checks help Paygate maintain the latest transaction state but do not replace the merchant's responsibility to retrieve the final result.
For all Event-cependent capture and refund requests, merchants should periodically call the Inquiry API until a final status (OK or FAILED) is returned.
No Inquiry polling is required for Single Immediate Payments because the merchant receives only the authorization result (AUTHORIZED) while Paygate manages capture and settlement transparently.