HomeGuidesAPI ReferenceChangelog
Log InChangelog
Guides
These docs are for v2025.11.00. Click to read the latest docs for v2025.12.00.

Aera Wallet API

This part of the documentation is only ment for developers implementing the White Label Wallet APIs

The Aera Wallet Infrastructure enables merchants to offer a customized Wallet solution in their merchant specific applications.

Aera Wallet Infrastructure context diagram

The following describes components and processes required for integrating the Wallet APIs. It provides detailed descriptions of the main components and their roles in delivering secure, efficient payment and voucher management services.

The Wallet Infrastructure allows users to seamlessly interact with their accounts, manage vouchers, and process payments while ensuring robust back-end security and functionality. These interactions occur through a series of structured APIs that facilitate communication between front-end applications and back-end systems. The APIs are designed to support authentication, voucher onboarding, payment processing, and balance management across various voucher types (e.g., meal vouchers, gift vouchers).


Breaking vs. non-breaking changes

Non-breaking changes tend to be additive: adding new fields or nested resources to the resource representations, adding new endpoints that were previously unavailable.

❗️

Code that is not yet in production, can add breaking changes without backwards compatibility.

📘

API consumers should build client code that is resilient to these kinds of non-breaking changes.

Breaking changes include:

  • Renaming fields and/or resource paths – often for clarity after the API is released.
  • Changing payload structures to accommodate the following: renaming or removing fields (even if they are considered optional – contracts!); changing fields from a single value to a one-to-many relationship (e.g. moving from one email address per account to a list of email addresses for an account)
  • Fixing poor choices of HTTP verbs, response codes, or inconsistent design across API endpoints

If a breaking change is encountered, API will be versioned unless it can be avoided by coordinating a temporarily backward compability accepted by all of the API consumers.


What’s Next