Reaching the records inside an AlinmaPay wallet

AlinmaPay holds a wallet ledger that can run without a linked bank account at all. Card issuance on the mada and Visa rails, SADAD bill payments, local and international transfers, and bill-splitting — each of those leaves a structured record tied to one authenticated identity. SAMA licensed the wallet back in 2020, per Alinma Bank's own news release, and it was the first wallet certified by Saudi Payments to push SADAD payments. For an integrator the question is narrow. Which of those records do you need, and which authorized route reaches them.

The short version: the wallet's own data sits in AlinmaPay's backend, not in a bank-account feed, so the dependable path to card spend, SADAD history and transfers is authorized interface integration of the app under the account holder's consent. Where a customer also holds an Alinma Bank account behind the wallet, the SAMA Open Banking consent flow adds a regulator-backed second source. We scope which records matter, then build against the route that actually carries them.

What an AlinmaPay account exposes

These are the surfaces a user already sees in the app. Each maps to a record an integrator can pull once access is arranged.

Routes to the wallet's data

Two routes carry real weight here, with a third used when we operate an account jointly with the client.

Authorized protocol analysis of the app

Under the account holder's authorization, we map the auth chain and the JSON the AlinmaPay app already receives — balance, card-transaction list, bill view, transfer history. This is the route that reaches the wallet-native records, because those records never leave the wallet's own backend. Effort is moderate; durability depends on how often the app revises its front end, which we account for in upkeep. This is the path we build the spine of the integration on.

SAMA Open Banking consent (AIS)

Where a user holds an Alinma Bank account linked behind the wallet, SAMA's account-information consent flow exposes that bank-account data through standardized, FAPI-secured APIs. It is regulator-backed and stable. Its limit is scope: AIS returns bank-account data, not the wallet's card or SADAD ledger, so it complements the protocol route rather than replacing it.

User-consented operated access

For a proof-of-concept or a low-volume need, we run the integration against an account the client consents to operate with us. Quick to stand up, narrower in reach. We arrange the access during onboarding.

Our recommendation for AlinmaPay is concrete: build the core against the protocol route, because the card, SADAD and transfer records the wallet is actually used for only exist there, and bring AIS in for the subset of users with a linked Alinma Bank account who want their bank side included too.

Deliverables for this build

You give us the app name and the records you want. What comes back, after delivery and once you are satisfied:

• An OpenAPI / Swagger specification for the wallet endpoints we map — balance, card transactions, SADAD bills, transfers.
• A protocol and auth-flow report: token issuance and refresh, device binding, and the request signing as it applies to AlinmaPay's session.
• Runnable source in Python or Node.js for the key endpoints, not just a stub.
• An automated test suite that exercises the live response shapes.
• Interface documentation an engineer can hand to the next person.
• PDPL-aligned consent-record and retention guidance for the data you keep.

A look at the request flow

Illustrative, and confirmed against real response shapes during a build — field names are normalized for the brief, not lifted verbatim from the app.

POST /wallet/auth/token
  body: { device_id, credential_grant }
  -> 200 { access_token, refresh_token, expires_in: 900 }

GET /wallet/transactions?card=primary&from=2026-05-01
  Authorization: Bearer <access_token>
  -> 200 {
       "balance": { "available": "...", "currency": "SAR" },
       "items": [
         { "id": "...", "rail": "mada", "merchant": "...",
           "amount": "-86.50", "ts": "2026-05-14T09:21:00+03:00",
           "type": "card_purchase" },
         { "id": "...", "rail": "sadad", "biller": "...",
           "amount": "-200.00", "status": "paid", "type": "bill" }
       ]
     }

# token expires_in is short; the client refreshes before each window
# rail field is what we use to split card spend from SADAD downstream

Consent and the Saudi regime

SAMA published its Open Banking Framework with the first AIS release in November 2022 and a payment-initiation (PIS) release in September 2024, per the framework trackers we cite below. The security profile is FAPI-aligned — mutual TLS, signed request objects, managed consent — and SAMA runs an Open Banking Lab for certification. Consumer data sits under Saudi Arabia's Personal Data Protection Law, in force since 2023, which requires consent that is informed, specific and revocable. We work to that: access is authorized and logged, consent records are kept, data is minimized to the records you actually asked for, and an NDA is in place where the engagement needs one. Where AIS is used, we honor the consent expiry and revocation the framework defines rather than caching beyond it.

What the build accounts for

A few things specific to AlinmaPay shape how we engineer the integration.

• Two card rails, one schema. Card activity arrives on both mada and Visa, and they describe a transaction differently. We normalize both into one record type so a downstream system never has to branch on rail.
• The no-bank-account case. Because the wallet runs standalone, many users have nothing for AIS to bind to. We design the core sync around the wallet ledger directly, and treat AIS as an add-on for the linked-account subset.
• Short-lived sessions. The wallet token expires quickly, so we build the sync around the refresh window and back-off behaviour so a long pull does not silently drop mid-run.
• SADAD vs card separation. Bills and card purchases land in the same activity stream; we tag them at ingest so obligations and discretionary spend stay queryable on their own.

When the app's front end shifts, we re-check the mapped fields as part of ongoing upkeep rather than waiting for a break. Access — a consenting account or, for the bank side, the SAMA consent flow — is arranged with you during onboarding.

Where this fits — three jobs

• A personal-finance product pulling AlinmaPay card transactions to categorize spend across mada and Visa.
• A treasury or SME tool reconciling SADAD obligations — zakah, taxes, commercial bills — against what was actually paid.
• A remittance dashboard syncing local and international transfer history for a customer who moves money through the wallet.

Screens we worked from

Sources and review

We worked from Alinma Bank's licensing announcements, the Google Play listing (package com.alinma.pay.consumer, per that listing), and the public SAMA Open Banking Framework trackers, in June 2026. Primary references:

• Alinma Bank — SAMA licenses AlinmaPay as a digital wallet
• SAMA Open Banking Framework — rules, standards and API spec (Fiskil tracker)
• Open Banking Expo — SAMA issues second release of the framework
• alinma pay on Google Play

Mapped and reviewed by the OpenBanking Studio integration desk, June 2026.

Other wallets in the same picture

A unified Saudi-wallet integration usually touches several of these; the data each holds rhymes with AlinmaPay's.

• STC Pay — the Saudi Telecom wallet, with stored balance, transfers and card spend.
• UrPay — Al Rajhi Bank's wallet, covering transfers, bill payments and virtual cards.
• Mobily Pay — Mobily's e-wallet for payments and top-ups.
• Tiqmo — a SAMA-licensed wallet with a Mastercard prepaid card.
• Friendi Pay — a wallet aimed at telecom-linked payments and bills.
• Hala — business-leaning payments with merchant and card records.
• barq — a digital wallet offering transfers and card services.
• Apple Pay — NFC card payments tied to most Saudi banks.

Questions integrators ask

Does AlinmaPay data come through SAMA Open Banking or from the app itself?

Both have a place. SAMA's AIS consent reaches a linked Alinma Bank account where one sits behind the wallet, but the wallet-native records — digital-card spend, SADAD bill history, bill-split shares — live in the app's own backend and are reached through authorized protocol analysis of its traffic. Most builds use the protocol route for the wallet ledger and layer AIS where a bank account is genuinely linked.

Can you separate digital-card spend from the SADAD bill payments?

Yes. They originate on different surfaces: card transactions ride the mada and Visa rails, while SADAD covers zakah, taxes, government fines and commercial bills. We normalize each into its own record type with a shared timestamp and identity key, so a downstream system can query spend and obligations independently.

What changes when an AlinmaPay user has no linked bank account?

AlinmaPay can run as a standalone wallet, so for those users there is no bank account for AIS consent to bind to. The integration is built around the wallet's own ledger instead — stored balance, card activity, transfers and bills — which is exactly the data the protocol route maps.

The engagement is plain. For a fixed scope we deliver runnable source from $300, billed only after delivery once you are satisfied; or you skip the build entirely and call our hosted endpoints, paying per call with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you need from its data on our contact page and we'll scope the route.