Merchant Store → Accepting Wallet Payments (ECR)
A guide for Merchant Store providers and retail decision makers
What is this about?
To accept Wallet payments in-store, your ECR (electronic cash register/Cashier system) must be able to initiate a Wallet payment request (Sale) and receive a response through a supported Payment Service Provider (PSP). This enables the checkout to trigger a digital wallet payment (e.g. Monizze, Edenred, Visa, Master Card and future payment methods) directly from the shopper’s mobile phone—just like a card, but smarter.
Why does the Cashier system need to do anything?
The Cashier system is responsible for starting the transaction and finishing it when payment is approved or declined. Everything in the middle—authentication, identity checks, balance verification—is handled by the Wallet infrastructure. That’s why the Cashier system must be able to:
- Tell the PSP: “We’re making a wallet payment for €X with this order ID.”
- Wait for the PSP to respond: “Wallet payment succeeded” (or failed).
- Continue the checkout: Print receipt, update backend, or prompt for another method.
What does the PSP do?
The PSP acts as your “wallet translator.” It takes the sale info from your Cashier system, adds a secure Aera token, and calls the Wallet API. Then, it listens for the wallet infrastructure to send back the signed transaction and process it, before receiving the result and forwards it to you and the mobile phone.
In short:
Merchant store ECR → PSP → Wallet API → Wallet Provider → Mobile App → Shopper signs → Wallet API → PSP → Acquirer → PSP → Cashier system
Your integration: What’s required?
| Step | Description |
|---|---|
| 1. Sale trigger | Cashier system (Merchant Store) sends the Payment information, and other wallet-specific fields (e.g. DPA ID) to the PSP. |
| 2. Await result | Cashier system shows a “Waiting for customer” screen while the wallet payment is processed. |
| 3. Handle response | PSP tells the Cashier system when the wallet payment is APPROVED, DECLINED, or EXPIRED. |
| 4. Proceed or retry | Cashier system either finalizes the sale (print receipt) or prompts for another payment method. |
| 5. Status or Cancel (Optional) | The Cashier system have the ability to request status or cancel a transaction. This works after the transaction has been initiated and before it is complete. |
What you don’t need to do
❌ No card terminals involved
❌ No direct calls to wallet APIs
❌ No handling of tokens, vouchers, or customer authentication
❌ No SecureID logic or SDK required on your side
Commercial and operational benefits
✅ New tenders without new hardware
✅ No sensitive data in the POS
✅ Fast settlement through your PSP
✅ Upgradable to support new wallet partners, vouchers, or payment schemes later
✅ Cashier-friendly experience: just another button on the payment screen
Summary
| You do | Trigger sale → Wait for response → Finalize or retry |
|---|---|
| PSP does | Secure token exchange, API call to wallet, async callback |
| Wallet does | Show UI to customer, manage authentication & approval |
Next steps
- Check with your PSP: “Do you support Aera’s Wallet Initiated Payment API?”
- Ensure your Merchant Store (Cashier system) can send wallet sales and receive async payment statuses.
- Test in staging with a live wallet user or test credentials.
- Go live with no changes to your card terminals.
For technical diagrams or implementation support, get in touch with your Aera Contact.
Updated about 2 months ago
