Retail Wallet Platform — Provider Dependencies
What each provider documents about availability, latency, rate limits, webhooks, idempotency and data residency — taken from their published documentation and API references, with sources at the bottom. Where a provider does not publish a figure, the row says so and lists it under open items with the date it was requested.
documented from the provider's public documentation · to confirm requested from the provider, answer pending · not published not documented; measured or contracted by us
Issuer processorWallester
Used for: card issuing, card accounts (funds system of record), authorisation and clearing, balance movements by account-to-account transfer (top-up load, discount return, cashback payout), push provisioning to Google Wallet and Apple Pay, KYC / KYB. The platform is not in the authorisation path: Wallester's real-time
DecisionRequest* webhooks (1 s answer budget in the API reference, 2 s in Wallester’s reply) exist and are not enabled for this programme.Facts below come from the Wallester Card API v1 OpenAPI specification (36 webhooks, 281 endpoints — including the Webhooks section that the doc SPA does not index), the Statuspage API of status.wallester.com, the Business Account & Card Agreement and the Privacy Policy, as of 9 September 2026. Wallester’s written replies of 10 and 14 September 2026 are recorded, with their date, in the rows they concern; where a reply differs from the API reference, both are shown. Quotes are verbatim. Availability figures are our own calculation from the status page, not a vendor statement.
| Item | What is documented | Status |
|---|---|---|
| Availability / SLA | Contractual uptime commitment: 99.5%; Wallester states historical uptime of 99.9% (reply, 14 September 2026). One figure was given, not split between card processing and the API. The public Business Account & Card Agreement suspends Wallester’s obligations during maintenance, so whether planned maintenance is excluded from the 99.5% is still to confirm. Status page with eight components — Payment Processing, Account Top-Up, Wallester Business API, Business Client Portal, White-Label API, White-Label Back Office, wallester.com, Sandbox — carrying 12 months of incident history, subscribable by e-mail, SMS, Slack or webhook, with an open Statuspage API (/api/v2/incidents.json) we can poll. Incidents are also e-mailed directly to programme partners. | 99.5% contractual · reply 14 Sep 2026 · maintenance exclusion, credits open |
| Availability — our calculation | 21 incidents since 3 June 2024. Duration measured from incident creation to closure on the status page; component weights not applied, so it is an upper bound on impact and a lower bound on two incidents closed with their opening timestamp. Weakest areas by incident history: tokenisation / Visa Token Service (a dedicated “Visa Token Service Disruption” and a 202-minute SyncTokens outage), clearing, and the Business API — the zone a wallet built on push provisioning inherits. Sandbox had two “critical” incidents in 2024 on its own: release CI must not be gated on it. Both full measured periods sit above the 99.5% commitment and below the 99.9% Wallester quotes; part of the gap is method, since every incident is counted here at full weight. | computed 9 Sep 2026 |
| Latency | Authorisation: up to 5 s end to end (Wallester, 14 September 2026). With real-time authorisation delegation enabled, the client has up to 2 s to return a decision; the API reference gives 1 s for DecisionRequest*. Neither applies here: the programme lets Wallester authorise on configured rules. Webhooks are dispatched immediately after authorisation processing; no p50 / p95 was given for delivery or for API calls. 499 and 504 are defined on every endpoint; the gateway timeout value is unstated. | reply 14 Sep 2026 · p50 / p95 not given |
| Rate limits | API reference: “Wallester has no rate limits and allows sending an unlimited number of requests to API, but we reserve the right to impose such limits if necessary.” Confirmed 14 September 2026: no artificial rate limits, no programme-level or per-product-code ceiling, and no specific ceiling on account transfers or push provisioning. Under extreme burst or overload the API returns 500 or 504 — no 429, no queueing. Platform load, 10 September: “typically several hundred RPS, with peaks exceeding 1,000 RPS”, with capacity added automatically. Our worst-case outbound rate is ≈ 20 requests / s. Consequence for us: a client-side token bucket and an outbound queue regardless, and no retry of a write on 500 / 504 without a lookup first. | documented · confirmed 14 Sep 2026 |
| Webhooks — catalogue | 36 events. Card lifecycle (CreateCardEvent, ActivateCardEvent, BlockCardEvent, ClosedCardEvent, ExpireCardEvent, RenewCardEvent, ReplaceCardEvent…); money movement (Authorization, ReversalAuthorization, ReleaseAuthorization, TransactionClearing, AccountAdjustmentNotification, AccountToAccountTransferNotification); KYC / KYB (KYCCheck, KYCStatusChange, KYBVerificationCheck); Apple Pay lifecycle; 3-D Secure OTP / validate; DecisionRequest* (optional, not enabled). Envelope is three fields — event, type, data — with no event id, sequence or timestamp at envelope level. | documented |
| Webhooks — authentication | HTTP POST with JSON to our URL. HTTP Basic auth only; HMAC signing is not supported (confirmed 14 September 2026). Mutual IP allow-listing is enforced: Wallester provides its static source IP ranges for our allow-list and allow-lists our addresses, so our API calls must leave from fixed egress IPs. X-Request-ID is stable across all retry attempts of the same event (confirmed) — it is our deduplication key, with (type, data.id) kept as a second check. | documented · confirmed 14 Sep 2026 |
| Webhooks — retries and ordering | Guaranteed delivery is optional and per event type, with two policies confirmed on 14 September 2026: Limited — up to 10 attempts; Mandatory — until a 2xx, at standard intervals for the first 10 attempts and then once every 24 h. Schedule in the API reference: 2 s → 5 s → 10 s → 10 min → 30 min → 1 h → 3 h → 6 h → 12 h → 24 h. The reference lists the types it can be enabled for — Authorization notification, Create card, Fee, Authorization release, Transaction clearing, KYC Check, Person KYC status change, Apple Pay orange flow — and account-to-account-transfer-notification is not among them; whether it can be enabled is open. Clearing arrives in near real time as it clears through Visa, day and night, not as a nightly batch. Ordering: no guarantee is documented and Wallester asked us to clarify the question; the ledger applies events as a state machine in any order regardless. | documented · confirmed 14 Sep 2026 · transfers, ordering open |
| Webhooks — replay | GET /v1/accounts/{id}/statement-by-cursor returns “account authorizations, transactions and adjustments” with a base64 cursor and move_forward; also statement-by-date and card statements. Gaps are closed by periodic reconciliation against this, not by relying on retries. | documented |
| Account-to-account transfers | Wallester, 14 September 2026: balance modifications are made with the Account-to-Account Transfer API, not POST /v1/account-adjustments, which is not applicable to this programme. This is how top-up load, discount return and cashback payout reach card accounts. The public OpenAPI specification (232 paths, fetched 14 September 2026) contains only the account-to-account-transfer-notification webhook — event, type, data.from, data.to — and no endpoint that creates a transfer. Endpoint documentation, the reference field, behaviour on a repeated reference, and whether a 500 / 504 may still have executed the transfer are requested. | reply 14 Sep 2026 · transfer API not in public spec · docs requested |
| Idempotency | No Idempotency-Key anywhere in the API. Card creation: “There is no built-in idempotency for card creation based on the request payload. If a card creation request is retried, a second, separate card will be created.” (14 September 2026). POST /v1/cards accepts an optional external_id — “Client-defined string identifier for the card … Must be unique” — and GET /v1/cards-by-external-id/{external_id} exists; whether a repeated external_id is rejected is not stated. Our protocol: every create carries a deterministic external_id; a timed-out or 5xx create is never retried blind — the card is looked up by external_id first; reconciliation flags any user with more than one active card. Account transfers: idempotency unknown until the transfer API is documented; the same lookup-before-retry rule applies. Account adjustments: not applicable to this programme. | reply 14 Sep 2026 · no idempotency on card create · repeated external_id open |
| Push provisioning | POST /v1/cards/{card_id}/push-provisioning/google-pay — client_wallet_account_id (“client-provided consumer ID that identifies the Wallet Account Holder entity”), client_device_id (“stable device identification set by Wallet Provider”), optional verify_cardholder (“cardholder will be prompted to verify himself using an OTP SMS/Email or Call center”) → encrypted_data. The green / yellow path is therefore our request parameter. POST …/push-provisioning/apple-pay — certificates, nonce, nonce_signature → activation_data, encrypted_data, ephemeral_public_key (canonical PassKit). Apple Pay has five webhooks (incomplete provisioning at 24 h and 7 d, successful transaction at 7 d and 14 d, orange flow); Google Pay has none — token status is polled via GET /v1/cards/{id}/tokens and POST …/sync-tokens (“synchronizes tokens with the latest information received from Visa”). The current specification adds POST …/push-provisioning/google-pay/opaque-payment-card — unified Android push provisioning. No throughput ceiling applies (14 September 2026). Wallester’s reply describes push provisioning as initiated from the wallet app and gives no latency or retry guidance; in the API these are server calls from our backend, so the question has been re-asked. App registration, entitlement sponsorship and verify_cardholder policy are unanswered. | documented · latency, retry, app registration open |
| Required headers | X-Product-Code mandatory on 245 endpoints — “Product, which this request belongs to (product code is defined by Wallester and specific for each client's product)”; one per product, assigned by Wallester. X-Audit-Source-Type (Backend / SelfService) and X-Audit-User-Id are mandatory too, so the initiating user's id is propagated through the platform end to end. | documented |
| Sandbox | Separate environment with its own status component. Parity with production and simulated authorisation / clearing / decline to confirm. | to confirm |
| Data residency / DR | Hosted on AWS in Ireland (EU), across multiple availability zones (Wallester, 14 September 2026); no UK residency option was offered. Wallester AS, Tallinn, is GDPR controller; the card-data environment is built on “PCI DSS-compliant AWS serverless components” with no human access. Backups are held apart from production, geographically replicated and encrypted in transit and at rest, with transaction-log recovery for databases and versioning for file storage. Recovery objectives for critical services: RTO 1–4 h depending on component; RPO ≈ 5 min for databases, up to 1 h for other critical components, near zero for file storage and security logs. Validated by quarterly restoration tests of critical assets and an annual business-continuity and DR exercise; the full procedure is confidential. Sub-processor list: with the DPA. | reply 14 Sep 2026 · sub-processors with DPA |
| Dependencies | Visa only — 9 mentions of Visa in the specification, none of Mastercard. Visible external dependencies: Visa / VTS, Apple Pay, Google Pay, Firebase Cloud Messaging, 3-D Secure OTP by SMS / email, an unnamed KYC / KYB vendor. Maintenance: 2–3 windows a month, almost always 00:30–02:30 EEST (21:30 UTC), announced on the status page and by e-mail in advance, notice period not stated; the agreement also allows unplanned maintenance without notice. Scheme certification is managed by Wallester as the issuing entity. | documented |
| Compliance | PCI DSS Level 1 — AoC provided with Wallester’s reply of 14 September 2026; auditor 7Security GmbH on the last public announcement. Visa Principal Member; scheme certification managed by Wallester. Estonian e-money licence. GDPR controller. ISO 27001: initial audit in progress. SOC 2 not mentioned. DPA for the UK programme: part of the formal agreement when issued. | AoC received · ISO 27001 in audit · DPA with agreement |
Availability computed from the status page
| Period | Incidents | Total, min | Computed availability | Worst incident |
|---|---|---|---|---|
| 2024 (from 3 June) | 7 | 120 | 99.96% | Sandbox, 66 min, critical |
| 2025 | 9 | 1,020 | 99.81% | 18 Nov — 234 min, API + portal |
| 2026 to 9 September | 4 | 461 | 99.87% | 8 Jan — 268 min, major, including Payment Processing |
| Planned maintenance | Windows | Total, min | Average window | Typical time |
|---|---|---|---|---|
| 2025 (from 5 March, last-50 sample) | 27 | 2,780 | 103 min | 00:30 EEST, weekdays |
| 2026 to 9 September | 23 | 2,685 | 117 min | 00:30 EEST, 2–3 × month |
Planned maintenance runs to roughly 45 hours a year — about 0.5% of the year, the entire margin of a 99.5% commitment — and the agreement suspends Wallester’s obligations during it. To fix in the contract: whether planned maintenance is excluded from the 99.5%, separate figures for authorisation and the Business API, service credits, a 7–14 day notice period for planned work, and quiet periods on our peak days.
Open questions for Wallester
Wallester answered in writing on 10 and 14 September 2026; the answers are recorded in the rows above. Closed: rate limits and overload response, X-Request-ID stability, retry policies, webhook authentication and IP allow-listing, clearing timing, contractual uptime, hosting region, RTO / RPO, PCI DSS AoC. Still open, ordered by impact on the design:
- Account-to-account transfer API. Please share the documentation for the transfer endpoints; they are not in the public OpenAPI specification. Which field carries our reference, is it enforced unique, and what is returned when it repeats? May a
500/504response still have executed the transfer, and how do we look a transfer up by our reference? Please confirm that one reference can never produce two credits, including when we retry after a timeout. - Guaranteed delivery for transfers. Can the Mandatory retry policy be enabled for
account-to-account-transfer-notification? - Card creation retries. If
POST /v1/cardsis repeated with the sameexternal_id, is the second request rejected with a recognisable error, or is a second card created? Canexternal_idbe made mandatory and enforced unique for our product code? - Webhook ordering, clarified. For one card, can
TransactionClearingorReversalAuthorizationbe delivered before itsAuthorization, for example while theAuthorizationdelivery is still being retried? Are new events to an endpoint held back while an earlier event is in retry? - Push provisioning, clarified. Our backend calls
POST /v1/cards/{card_id}/push-provisioning/google-pay,…/apple-payand…/google-pay/opaque-payment-cardto obtain the encrypted payload for the wallet app. What latency and client timeout should we expect, and is a retry safe? Also: what you need from us to register Embargo’s Android app for Google Pay push provisioning and the lead time; whether you sponsor the Apple in-app provisioning entitlement; whetherverify_cardholderis mandatory; and whether each partner programme needs its ownX-Product-Code. - Authorisation without delegation. Which configured rules apply when delegation is off — balance, MCC or merchant restrictions, velocity limits — and which can be changed via API in real time? Do cards continue to authorise under Visa stand-in if the Wallester platform is unavailable?
- SLA detail. Does the 99.5% cover card processing and the API alike, is planned maintenance excluded, what notice period applies to planned work, and are there service credits?
- Refunds and chargebacks. When a merchant refunds a settled purchase, does the
TransactionClearingevent withgroup = Refundreference the original purchase —authorization_id, original transaction id or acquirer reference number — and are partial refunds identified? How are chargebacks notified?
Payment service providerStripe
Used for: card top-ups, saved cards (vault), 3-D Secure, Apple Pay / Google Pay inside the payment sheet. Merchant of record: Retail Wallet. Card data goes from the device to Stripe; neither the platform nor the partner backend sees a PAN.
| Item | What is documented | Status |
|---|---|---|
| Availability / SLA | Public status page with 90-day availability for the API, site and Stripe.js, subscribable by email / RSS / webhook. No contractual SLA in the standard Services Agreement — enterprise terms to be discussed with the account team. | status page · SLA to confirm |
| Latency | Not published. Stripe notes that sandbox latency differs from live (“creating a charge in live mode sends a request to a payment gateway and that request is mocked in a sandbox”) and recommends mocking Stripe in load tests using measured live durations — which is what the platform's load test does. Sheet confirmation includes 3-D Secure and depends on the issuing bank. | not published · measured by us |
| Rate limits | Global 100 requests / s live, 25 in sandbox; individual endpoints 25 requests / s; 1,000 update requests per PaymentIntent per hour; concurrency limits separate from rate limits; read allocation of 500 GET requests per transaction over a rolling 30 days (minimum 10,000 / month). Signalled by 429 with Stripe-Rate-Limited-Reason (global-rate, endpoint-rate, global-concurrency, endpoint-concurrency, resource-specific); 429 lock_timeout on concurrent access to one object. “If you suspect that an upcoming event might push you over the limits … contact Stripe Support.” | documented |
| Webhooks | HTTPS, TLS 1.2 / 1.3 only. Signed: Stripe-Signature header, HMAC-SHA256 over timestamp.body, default 5-minute tolerance; source IP list published for allow-listing; secrets can be rolled with a 24-hour overlap. Retries: “for up to three days with an exponential back off in live mode”; sandbox: three retries over a few hours. No ordering guarantee — “Track event IDs to identify duplicate deliveries”. Manual resend up to 15 days (Dashboard) / 30 days (CLI). Up to 16 endpoints. Events can also be delivered to Amazon EventBridge. | documented |
| Idempotency | Idempotency-Key header on all POST requests; the first result (including 500) is stored and replayed; keys up to 255 characters; pruned after at least 24 hours; reuse with different parameters returns an error. GET / DELETE are idempotent by definition. | documented |
| Sandbox | Isolated sandboxes per account; lower rate limits; card networks mocked. Stripe discourages load-testing against a sandbox. | documented |
| Data residency | Accounts outside the Americas contract with Stripe Payments Europe Ltd (Ireland) under Stripe's DPA; Stripe Technology Company Ltd (Ireland) is the GDPR main establishment. Data may be transferred to the US under Stripe's Data Transfers Addendum. No UK-only storage option on standard terms. | documented · UK option to confirm |
| Dependencies | Card networks, issuing banks and their 3-D Secure access-control servers, acquiring. Payout timing to our settlement account (T+n for UK) determines the float we hold at the issuer. | payout timing to confirm |
| Compliance | Stripe Payments UK Ltd — FCA-authorised electronic money institution (reference 900461). PCI DSS Level 1 Service Provider, certified annually by a QSA. | documented |
Open items
- Contractual SLA on enterprise terms; payout schedule for our account; limit increases ahead of campaign days; UK data-residency options
Open bankingPlaid
Used for: pay-by-bank top-ups (UK Payment Initiation over Faster Payments) and identity verification. Bank authorisation happens from the device inside Plaid Link; the platform creates the session and consumes the result.
| Item | What is documented | Status |
|---|---|---|
| Availability / SLA | Public status page for the three API environments; institution-level status available in the dashboard and over the API. Uptime SLA and support response-time SLA are part of the enterprise package that comes with the Custom plan EU / UK customers are on — the contractual figures are recorded here once countersigned. | status page · SLA figures to obtain |
| Latency | Not published — and bank-dependent by nature. Payment lifecycle: INPUT_NEEDED → AUTHORISING → INITIATED (“authorised and accepted by the financial institution”) → EXECUTED (“funds have left the payer's account”); SETTLED only with Plaid Virtual Accounts. Failures: INSUFFICIENT_FUNDS, FAILED, BLOCKED, REJECTED, CANCELLED. “Payments sent via Faster Payments will typically arrive immediately.” | not published · bank-dependent |
| Rate limits | Per client: /payment_initiation/payment/create 240 / min; /payment_initiation/consent/create 100 / min; /identity_verification/create 120 / min, /get 420 / min; /link/token/create 20,000 / min; /item/public_token/exchange 12,000 / min. Per Item on data endpoints (e.g. /accounts/get 15 / min). Signalled by 429, error_type RATE_LIMIT_EXCEEDED with a per-endpoint error_code; INSTITUTION_RATE_LIMIT when the bank itself throttles. “Contact your account manager or file a Support request” to raise. | documented |
| Webhooks | Verified with the Plaid-Verification JWT (ES256), public key from /webhook_verification_key/get, body SHA-256 in the token, iat not older than 5 minutes. Retries: “If there is a non-200 response or no response within 10 seconds … Plaid will keep attempting to send the webhook for up to 24 hours” (backoff from 30 s, ×4). “If you (or Plaid) experience downtime for longer than Plaid's retry period, you will lose webhooks” — so in-flight payments are also polled with /payment_initiation/payment/get. Duplicates and out-of-order deliveries are expected. Four source IPs published (subject to change). Payment updates arrive as PAYMENT_STATUS_UPDATE. | documented |
| Idempotency | Payment creation uses a reference (“each payment must have a unique reference. If the reference provided through the API is not unique, Plaid will adjust it”) — at most 18 characters, no special characters; our top-up id is the reference. Reversals and consent execution take an explicit idempotency_key. | documented |
| Sandbox | /sandbox/payment/simulate drives a payment through its statuses; test institutions for Link. | documented |
| Data residency | UK / EEA personal data processed under UK GDPR / GDPR; UK / EU hosting is available on the Custom plan — the contracted region is recorded here from the agreement. | available · region to record |
| Dependencies | Each bank's Open Banking API (per-institution status and throttling), Faster Payments; consent expiry for data products (90 days). | documented |
| Compliance | Plaid Financial Ltd (UK) — authorised by the FCA under the Payment Services Regulations 2017, FRN 804718, for account information and payment initiation services (since 2019); Plaid B.V. for the EU. SOC 2 report available under NDA. | documented · SOC 2 report to obtain |
To obtain from Plaid — all available on the Custom plan
- Contractual SLA figures (uptime, support response) — from the countersigned agreement
- Limit increases for
payment/create(default 240 / min) andidentity_verification/create(default 120 / min) to launch volumes — via the account manager - Contracted UK / EU hosting region — from the agreement
- SOC 2 report — under NDA
- Supported UK document list for identity verification — from the product documentation for our configuration
ReferencesSources
- Wallester — Card API v1 reference (rate limits statement; Webhooks section incl. retry schedule and delivery modes; cards; account-to-account transfer notification; statements; push provisioning; headers — fetched 14 September 2026), status.wallester.com — incident history (Statuspage API export, 9 Sep 2026), Business Account & Card Agreement, Privacy Policy, PCI DSS Level 1, Visa Principal Member, written replies from Wallester to Retail Wallet of 10 and 14 September 2026 (e-mail; PCI DSS AoC attached to the latter)
- Stripe — Rate limits, Webhooks, Idempotent requests, Status, European data transfers, DPA, Stripe Payments UK Ltd, Security at Stripe
- Plaid — Rate limits, Webhooks, Webhook verification, Payment Initiation, Status, Plans, Support packages, FCA register — Plaid Financial Ltd
Retail Wallet Platform — Provider Dependencies · 15 September 2026 · Companion: Architecture & capacity specification · Partner API reference