Scenario 1: Card Payments with Aera´s Hosted Checkout Page
This section describes common card payment flows using the Aera Hosted Checkout Page.
All card scenarios start by creating a checkout session and redirecting (or embedding) the shopper to the returned checkoutUrl.
Card payments follow an authorization–capture model and support:
- Authorization only
- Immediate capture
- Single full capture
- Multiple partial captures (split shipment)
- Card verification (zero-amount authorization)
- Optional card storage (Credentials on File)
- Initial standing instruction for subsequent recurring payments
1. Card Authorization – Single Full Capture
The shopper authorizes the payment on the Aera Hosted Checkout Page.
The merchant later performs a single full capture.
Sequence Diagram
sequenceDiagram
title Checkout – Standard Hosted Checkout
autonumber
participant Shopper
participant MB as Merchant Backend
participant Aera
%% Create Checkout Session
Note over Shopper,Aera: Create Checkout Session
Shopper->>MB: Initiate checkout
MB->>Aera: POST /v1/session/payment/create
Aera->>Aera: Validate request
Aera-->>MB: sessionInfo (pspReference, checkoutUrl)
MB-->>Shopper: Redirect to checkoutUrl
Note over Shopper,Aera: Shopper completes payment on Aera Hosted Checkout Page
Shopper-->>MB: Redirect (success / cancel / error)
%% Notify Merchant
Note over MB,Aera: Notify Merchant
alt Webhook
Aera-->>MB: CHECKOUT_SESSION_COMPLETED (pspReference)
MB->>Aera: Acknowledge
end
%% Merchant Fetches Status
Note over MB,Aera: Merchant Fetches Status
alt Status API
MB->>Aera: GET /v1/{pspReference}/status
Aera-->>MB: Payment status + operations
end
%% Capture by Merchant
Note over MB,Aera: Capture by Merchant
MB->>Aera: POST /v1/{pspReference}/capture (Full amount)
Aera-->>MB: Capture response
Step 1 – Create Session
POST /v1/session/payment/create{
"header": {
"merchantId": "MER100000",
"idempotency-key": "UUID v7"
},
"body": {
"merchantInfo": {
"successRedirectUrl": "https://frontend.merchant.com/success",
"cancelRedirectUrl": "https://frontend.merchant.com/cancel",
"errorRedirectUrl": "https://frontend.merchant.com/error",
"webhookUrl": "https://backend.merchant.com"
},
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": false,
"amountDetails": {
"amount": 10000,
"currency": "NOK"
}
},
"paymentMethodInfo": {
"paymentMethodWhitelist": ["CARD"]
}
}
}Step 2 – Session Created Response
{
"responseInfo": {
"responseCode": 0,
"responseText": "Success"
},
"sessionInfo": {
"pspReference": "UUID v7 generated by Aera",
"checkoutUrl": "https://checkout.aera.com/<sessionId>"
}
}Redirect the shopper to checkoutUrl and wait for Webhook.
Step 3 – Webhook (Session Completed)
{
"eventType": "CHECKOUT_SESSION_COMPLETED",
"status": "0",
"pspReference": "UUIDv7 from Create response",
"merchantReference": "12344333",
"paymentMethod": "CARD",
"paymentScheme": "VISA"
}Step 4 – Capture
POST /v1/{pspReference}/captureNo body → full capture.
2. Card Authorization – Store Card (Credentials on File)
This scenario allows the shopper to store the card for future use in addition to completing the payment. The stored card can be used for a faster checkout next time where the shopper does not need to enter the card details again.
Sequence Diagram
sequenceDiagram
title Checkout – Store Card (Credentials on File)
autonumber
participant Shopper
participant MB as Merchant Backend
participant Aera
%% Create Checkout Session
Note over Shopper,Aera: Create Checkout Session
Shopper->>MB: Initiate checkout
MB->>Aera: POST /v1/session/payment/create (with paymentInstrumentsProfileData)
Aera->>Aera: Validate request
Aera-->>MB: sessionInfo (pspReference, checkoutUrl)
MB-->>Shopper: Redirect to checkoutUrl
Note over Shopper,Aera: Shopper completes payment on Aera Hosted Checkout Page\nand selects "Store card"
Aera->>Aera: Create stored credential entry (Credentials on File)
Shopper-->>MB: Redirect (success / cancel / error)
%% Notify Merchant
Note over MB,Aera: Notify Merchant
alt Webhook
Aera-->>MB: CHECKOUT_SESSION_COMPLETED (pspReference)
MB->>Aera: Acknowledge
end
%% Merchant Fetches Status
Note over MB,Aera: Merchant Fetches Status
alt Status API
MB->>Aera: GET /v1/{pspReference}/status
Aera-->>MB: Payment status + STORED_CREDENTIALS operation
end
%% Capture by Merchant
Note over MB,Aera: Capture by Merchant
MB->>Aera: POST /v1/{pspReference}/capture (Full amount)
Aera-->>MB: Capture response
Additional Request Parameter
"paymentInstrumentsProfileData": {
"merchantShopperId": "LOYAL-70018882",
"storePaymentInstrument": "OPTIONAL"
}If card storage is enabled for the merchant, the checkout page presents a “store card” option. If set to MANDATED, the option is prechecked and gray, i.e. storing the card is mandated and the shopper is not allowed to de-check.
The status response includes an additional operation:
{
"type": "STORED_CREDENTIALS",
"status": "COMPLETED",
"details": {
"merchantShopperId": "LOYAL-70018882",
"pspShopperId": "UUID",
"paymentInstrumentReference": "UUID"
}
}3. Card Authorization – Stored Cards Only
This scenario restricts the checkout to previously stored cards, meaning the shopper has to complete payment with a stored card. There is not option to manually enter card details.
Typical Use Cases
Restricting checkout to previously stored cards is typically used in:
- Returning customer flows where the shopper is already authenticated and has a stored payment method.
- Subscription or recurring billing models where payment must be made using an approved card on file.
- Loyalty or membership programs where purchases are tied to a known customer account.
- One-click checkout experiences designed to minimize friction and improve conversion.
Sequence Diagram
sequenceDiagram
title Checkout – Pay with Stored Card Only
autonumber
participant Shopper
participant MB as Merchant Backend
participant Aera
%% Create Checkout Session
Note over Shopper,Aera: Create Checkout Session
Shopper->>MB: Initiate checkout
MB->>Aera: POST /v1/session/payment/create\n(with allowStoredInstrumentsOnly = true)
Aera->>Aera: Validate request
Aera-->>MB: sessionInfo\n(pspReference, checkoutUrl)
MB-->>Shopper: Redirect to checkoutUrl
Note over Shopper,Aera: Shopper selects from previously stored cards only.\nManual card entry is not available.
Shopper-->>MB: Redirect (success / cancel / error)
%% Notify Merchant
Note over MB,Aera: Notify Merchant
alt Webhook
Aera-->>MB: CHECKOUT_SESSION_COMPLETED\n(pspReference)
MB->>Aera: Acknowledge
end
%% Merchant Fetches Status
Note over MB,Aera: Merchant Fetches Status
alt Status API
MB->>Aera: GET /v1/{pspReference}/status
Aera-->>MB: Payment status + operations
end
%% Capture by Merchant
Note over MB,Aera: Capture by Merchant
MB->>Aera: POST /v1/{pspReference}/capture\n(Full amount)
Aera-->>MB: Capture response
Additional Request Parameter
{
"paymentInstrumentsProfileData": {
"merchantShopperId": "LOYAL-70018882",
"allowStoredInstrumentsOnly": true
}The checkout page displays only stored cards.
4. Immediate Capture (Authorization + Capture)
In this scenario, authorization and capture occur in a single step. When creating the Checkout session, you set immediateCapture to true such that a separate Capture is not required.
Request Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": true,
"amountDetails": {
"amount": 10000,
"currency": "NOK"
}
}
}The status response will include both:
AUTHORIZATIONCAPTURE
If capture fails, the transaction is reversed.
5. Split Shipment – Multiple Partial Captures
This scenario supports multiple captures for a single authorization. In this case, you set splitShipment to true.
Session Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": false,
"splitShipment": true,
"amountDetails": {
"amount": 10000,
"currency": "NOK"
}
}
}Partial Capture Example
POST /v1/{pspReference}/capture{
"amountDetails": {
"amount": 5000,
"currency": "NOK"
}
}Additional captures may be performed until the full amount is captured.
6. Card Verification (Zero-Amount Authorization)
This scenario verifies the card validity without charging the shopper.
Request Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": false,
"storePaymentInstrument": true,
"amountDetails": {
"amount": 0,
"currency": "NOK"
}
}
}This performs a zero-amount authorization with mandated storage of the card. Implicitly this forces explicit authentication.
7. "One-click" payment using a stored card
This scenario is using the Authorize endpoint for intiating a payment referring to a prior stored card and without showing the checkout UI.
If the amount is lower than the low-value exemption limit (currently 300 NOK, 30 EUR) the payment is initiated as a low-value exemption payment. If approved there is no shopper interaction. The checkoutUrlin the response is then empty.
If low-value exemption is "soft-declined" by the issuer (authentication required) or the amount is higher than the low-value limit, authentication is required and the checkoutUrlin the response need to be rendered by the merchant. The authenticaton may be frictionless or require explicit shopper authentication.
Request Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": true,
"merchantShopperId": "LOYAL-70018882",
"paymentInstrumentReference": "....",
"amountDetails": {
"amount": 100,
"currency": "NOK"
}
}
}8. Storing card for subsequent recurring payments
This scenario describes the initial standing instruction for subsequent recurring payments using Create MIT endpoint .
Request Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": true,
"recurringProcessingInfo": {
"recurringModel": 0,
"recurringFrequency": 28
},
"amountDetails": {
"amount": 200,
"currency": "NOK"
}
}
}This sets up an initial standing instruction for a monthly standing order / subscription with variable amount. The initial payment (first term) is 200 NOK, but this amount is not linked to the future recurring payments.
The merchant must store the recurringReference from the response of the Status request and use it for the subsequent recurring payments.
9. Merchant-initiated recurring payment
This scenario is using the Authorize MIT endpoint for intiaing recurring payments. It requires a prior approval by the shopper and storing a card for subsequent recurring payments.
Request Configuration
{
"transactionData": {
"merchantReference": "12344333",
"immediateCapture": true,
"merchantShopperId": "LOYAL-70018882",
"paymentInstrumentReference": "....",
"amountDetails": {
"amount": 100,
"currency": "NOK"
}
}
}Validation Considerations
For card payments to be available:
- Merchant must have at least one acquirer configured
- At least one card scheme must be enabled
- Acquirer must support the configured service, MCC, and operation type
Availability and behavior may vary depending on:
- Acquirer capabilities
- Scheme rules
- Merchant configuration
Updated 13 days ago