How to test neobank virtual card limits

Neobank virtual card limit testing verifies that a digital card's configured spending rules are applied correctly when payments are authorised, adjusted, reversed or cleared. It checks permitted transactions at limit boundaries, confirms that rejected transactions leave balances and limit usage consistent, and validates how card, account and time-window rules interact across the app, banking application programming interfaces (APIs) and card processor.

Define the limit rules first

Before writing tests, identify what each limit controls. A product may set a maximum per transaction, a daily or monthly spending cap, or a limit over a rolling period. Rules may apply to a card, a customer account or a card category. Confirm which rule takes precedence if several apply, and whether cash-like transactions, particular merchant categories, currencies or recurring payments are treated differently.

Record the limit amount, currency, period start and reset rule, and the transaction states that count towards usage. Clarify whether the system evaluates the requested authorisation amount, the final cleared amount or another defined amount. These details are product and processor dependent, so avoid assuming that two cards with the same displayed limit share the same calculation.

Design boundary and lifecycle tests

Use boundary value analysis around each configured threshold. For a hypothetical per-transaction limit of £100, test £99.99, £100.00 and £100.01, provided the product accepts those increments. Assert the authorisation decision and the amount recorded against the limit. Repeat with an existing usage amount that leaves precisely enough capacity for the next transaction.

Also cover a zero limit, a limit below the minimum transaction amount, and changes to a limit while the card is active. Test the behaviour when a card is frozen, expired or replaced, according to the product rules. These cases help expose incorrect validation, stale limit values and differences between the customer interface and the authorisation service.

A card payment can move through authorisation, clearing and reversal. An authorisation may reserve funds or limit capacity before a merchant submits the final amount. Test whether the hold reduces available limit, how an adjusted or incremental authorisation changes usage, and when a reversal releases it. Check that a refund is handled according to the defined policy; refunds may affect account balances and limit usage differently.

Check time windows, currency and concurrency

For daily or monthly limits, test transactions immediately before and after the reset boundary. Verify the configured time zone and whether the period is a calendar interval or a rolling window. Include daylight-saving clock changes where the service uses local time, and check how delayed clearing affects the period to which a transaction is attributed.

For foreign-currency transactions, verify the currency conversion source and point in the payment lifecycle used for limit evaluation. Assert the stored original amount and currency as well as the converted amount, rounding and limit usage. Do not assume the amount shown to the cardholder is the amount used by the authorisation rule.

Run concurrent authorisation requests when the rule is an aggregate cap. For example, if £30 remains and two £20 payments arrive at almost the same time, verify that the configured policy cannot approve both and exceed the limit. Check idempotent retries too: resending the same request must not consume limit capacity twice.

Verify outcomes across systems

Test through the customer app and the relevant API or processor integration. Check that a limit change is validated, persisted and used by subsequent authorisations. Verify response status and reason where available, then compare limit usage, pending holds, transaction history and customer notifications. A declined transaction should not create a completed payment or leave an unintended hold.

After each scenario, inspect the authoritative records used by the product, such as card-service state, processor events and ledger entries. Reconcile totals after clearing, reversal or refund so that retries and delayed events do not create duplicate usage. Keep test data isolated from live payment routes, and reset card state and transaction history between cases.

Worked example

Assume a test card has a £100 per-transaction cap and £40 of a £200 daily cap has already been consumed. Submit a £100 purchase, then a £100.01 purchase. The first may pass the per-transaction check while remaining within the daily cap; the second should fail that check if the rules use the requested authorisation amount. Next, submit a £160 purchase: it is below the per-transaction cap only if the cap is changed, so keep the configured values explicit in the test. For a clean aggregate check, use a separate case with a £200 per-transaction cap: a £160 request exceeds the £160 daily capacity remaining only if the day's prior usage is £40 and the daily cap is £200, so assert the documented limit decision and confirm rejected usage remains unchanged. This example demonstrates why each test should state both applicable limits and prior usage rather than infer the outcome from one threshold.