Welcome!

This guide gives you a high-level understanding of how the Aera Wallet works — and what role your business or platform plays in it.

Whether you’re building a loyalty app, enabling in-store payments, or processing transactions as a PSP, this is your starting point.

The Building Blocks of the Aera Wallet

The Aera Wallet is made up of three core components — each with a clear role in the payment journey:

1. Mobile App (DPA)

The customer-facing app that hosts the Wallet

This is your mobile app — the primary channel where users access the Wallet. It’s often a loyalty app, branded portal, or self-checkout experience. Aera provides an SDK that is embedded directly into your app and fully styled to match your visual identity.

From the user’s perspective, this is where they:

• Register and authenticate (e.g. BankID or itsme®)
• Add cards and vouchers
• View their Wallet dashboard
• Approving or Rejecting payments when check in your store.

From your perspective, the Mobile App is where you:

• Control the user journey
• Embed the Aera Wallet SDK
• Use Aera APIs to initiate wallet sessions
• Own the login and visual experience

Learn more about the Mobile App

2. Wallet Provider (WSP – Wallet Provider)

The QR-based flow connecting your store to the Wallet

Mobile Wallet is what enables the customer to pay with the Wallet by scanning a QR code at checkout. This flow is designed for in-store, self-checkout and online environments where speed, clarity, and payment flexibility are essential.

It works like this for in-store:

• Your Merchant Store (ECR - Electronic Cash Register) or Mobile app generates a QR code
• The customer scans it with their Mobile App or a scanner at the ECR
• The Merchant Store initiate the transaction
• Aera receives the transaction request and routes it to the correct payment method (In this case, your wallet)
• Once confirmed, your system receives a success/failure response

It works like this for online

You configure:

• Accepted payment methods (Visa, Mastercard, BankAxept, vouchers, etc.)
• Supported identification methods
• How confirmations are shown on screen or via printed receipts

This is how Wallet payments come to life in the store.

Learn more about Merchant Pay

3. PSP (Payment Service Provider)

Handles transaction processing after Wallet confirmation

Once the customer confirms the payment inside the Wallet, the transaction is handed off to a PSP for processing.

The PSP:

• Authorizes the transaction
• Clears and settles the payment
• Returns the result to the Aera Wallet backend and ECR

The Aera PSP is currently the only connected PSP and will help you process your transactions.

You can:

• Add support for new payment methods (cards, vouchers)
• Choose routing logic depending on cost, type, or brand

Learn more about PSP Integration

4. Merchant Store (ECR)

Where payments start — and the checkout experience is owned

The Merchant Store is the first actor in any in-store Wallet payment. Whether it’s a self-checkout kiosk, cashier interface, or a connected scanner, it’s responsible for:

• Triggering the transaction flow
• Displaying or printing the QR code
• Sending the transaction to the PSP

Here’s how it fits into the Wallet journey:

1. The Merchant Store generates a transaction request, which is routed to the PSP.
2. The PSP forwards the request to Aera, which checks for a Wallet session and routes it to the right Wallet Provider.
3. Once the customer confirms the payment in their Wallet, the result is returned to the PSP and back to the Merchant Store.
4. The Merchant Store finalizes the checkout based on the result — printing receipts or showing success/failure.

The Merchant Store doesn’t talk directly to the Wallet — it initiates the transaction that flows through PSP → Aera → Wallet → Wallet Provider → Mobile App

What the Merchant Store controls:

• Sale initiation
• Payment amount, receipt generation
• Display of QR code (if used)
• What happens on success/failure

What it doesn’t control:

• Authentication
• Payment UI
• Payment method availability

Example Scenarios

• A grocery chain embeds the Wallet in their loyalty app → Users store Visa cards and scan a QR at self-checkout.

• A voucher partner connects to the Wallet → Customers can add and use stored voucher balance for eligible purchases.

• A PSP enables Wallet support for multiple merchants → Offer partner chains to connect to the Wallet → Increased brand recognition and usage

Who Should Read This?

This page is designed for:

• Product managers planning Wallet functionality
• Platform or integration leads
• Business decision makers mapping out user journeys
• Retail or PSP partners considering Wallet support

You don’t need to be technical yet — just familiar with your role in the customer experience.

What You Can Do Next

• Learn how your app becomes a Mobile App (DPA)
• Understand how in-store payments work via Wallet Provider (WSP)
• See how the PSP fits into the Wallet architecture
• Decide which roles your team will take on

📌

If you're a retailer, you may be all three: Mobile App + Wallet Provider + Merchant Store.

📎 What’s Next?

• Start with your Mobile App
• Set up your Wallet Provider