BaaS and partner bank integration testing

What BaaS and partner bank integration testing includes

We test the boundary between your product and the BaaS provider or partner bank behind it: the calls you make, the events you receive, and the limits the bank sets. The Banking-as-a-Service segment page covers ledger failures against the bank core and the supervisory expectations behind them. Sources below were checked on 2026-09-16.

Provider API contracts

• Status and schema drift. Contract tests compare every response the product reads with the provider's API specification and with recorded sandbox responses. A provider that adds a bank-initiated account restriction status breaks a client that maps unknown statuses to "active", and the product keeps accepting transfers into a restricted account.
• Amounts. Create, read, and list calls round-trip amounts in minor units and as decimal strings, including currencies whose ISO 4217 minor unit is not 2. A client that assumes two decimal places shows a wrong balance for every such account.
• Errors and retries. Each provider error maps to one product state and one customer message. A 429 rate-limit response shown as a decline tells the end user that a payment failed, and a later retry without the original idempotency key sends the payment twice.
• List pagination. Transaction list calls run across page boundaries while new items post. A cursor that skips an item posted mid-page removes the item from the product's daily reconciliation.

Generic contract generation and API version checks for your own public API belong to API and webhook testing.

Webhook delivery, ordering, and retries

• Duplicates. Each provider event arrives twice, once with a new delivery ID, and the ledger shows one posting. The BaaS webhook reliability guide describes the replay harness.
• Out-of-order events. An ACH return event delivered before its settlement event leaves the transfer returned. A handler that applies events in arrival order marks the credit settled after the return and releases funds that the programme reserve then covers.
• Undelivered events. The endpoint fails until the provider's retry schedule ends. The backfill job that reads the provider's event list must repair the product state; without it, a card that the partner bank closed stays active in the app.
• Signatures. HMAC signatures are verified on the raw request body, both secrets pass during a secret rotation, and a replayed event outside the timestamp tolerance fails.

Programme controls and limits

• Limits per channel. Values below, at, and above each per-transaction, daily, and per-end-user limit run through the app, the API, batch upload, and scheduled transfers.
• Concurrency. Two requests in the same second each pass the daily limit alone and exceed it together. A check that reads the used amount before either request posts approves both.
• Reset and change timing. Daily limits reset in the time zone the programme agreement names, and a limit the bank lowers mid-day applies to the next request.
• Gates. No card is issued and no ACH debit is originated before KYC approval, and Nacha Rules Subsection 2.5.17.4 requires validation of a WEB debit account number before its first use and after any change to it (Nacha testing requirements).
• Consumer disputes. A notice of error that the app accepts reaches the provider's dispute API with its received time. The test checks the timer for 12 CFR 1005.11(c)(1), under which the financial institution shall investigate promptly and, except as provided in (c)(2) and (c)(3), determine whether an error occurred within 10 business days of receiving the notice (Regulation E testing requirements covers the extensions).

Nacha's summary of the Third-Party Sender Roles and Responsibilities rule (effective 30 September 2022) lists setting and enforcing customer exposure limits among the ODFI risk management requirements. A limit bypass lets an Originator send debits above the exposure limit the ODFI set. Any debit returned as R10 (unauthorised) counts toward the Originator's 0.5% unauthorised return rate threshold in Nacha Rules Subsection 2.17.2.

Partner bank due diligence evidence

• Test records. Each run records the provider API version, the environment, the run date, and the change ticket, so the same records serve SOC 2 change management sampling under CC8.1.
• Card data scope. Where the product or the platform handles cardholder data, the pack lists which PCI DSS v4.0.1 requirements each party manages, the split that service providers give upon customer request under requirement 12.9.2 (PCI DSS testing requirements).
• Service provider assessment. A financial institution under the FTC Safeguards Rule must periodically assess its service providers based on the risk they present and the continued adequacy of their safeguards (16 CFR 314.4(f)(3)). The evidence pack is input to that assessment of a BaaS provider: API contract results, webhook delivery results, and limit and gate results against the programme agreement.