Open banking consent revocation testing verifies that withdrawing a customer’s permission stops the authorised provider from accessing the specified account data or initiating activity covered by that consent. It checks the consent state, API authorisation and downstream behaviour against the applicable open banking scheme and product requirements, including how quickly access must stop and what happens to data already obtained.
Define the revocation behaviour
Start with the consent contract and the systems involved. An account information service (AIS) consent may authorise access to account details or transaction history. A payment initiation service (PIS) consent may relate to a particular payment, while a separate authorisation can govern ongoing access. Test the relevant consent types independently because their lifecycles and revocation effects can differ.
Record what revocation must do in your implementation: which party can initiate it, which status the consent enters, which API calls become unavailable, and when those changes take effect. Confirm whether revocation applies to every account and permission in a consent or only a defined subset. Use the scheme and product requirements as the source for expected responses and timing; endpoint names, status codes and token behaviour vary between implementations.
Consent state and credential state are related, but they are separate things to verify. A system may retain a previously issued access token until expiry, revoke it immediately, or use another control to reject requests. Test the required outcome at the resource API, including requests using an existing token and any refresh token. A successful revocation response alone does not prove that access has stopped.
Prepare the test environment
Use a dedicated customer, consent, account and third-party provider identity in a controlled environment. Keep test data isolated so that one test cannot revoke consent needed by another. Capture the initial consent state and permissions, and ensure the test account contains data that would make an unauthorised read observable.
Map the full path from the customer-facing revocation action to the consent service, authorisation server and resource API. Include any event, cache or gateway involved in access decisions. Where a dependency is simulated, retain at least one integration test against the connected components that enforce the revocation. Check system clocks and asynchronous processing, since delays can affect time-based assertions.
Test the consent lifecycle and blocked access
Cover a successful revocation through each supported channel, such as the bank’s interface or a third-party provider’s interface where applicable. Verify that the customer receives an accurate outcome and that the recorded consent state changes as specified. Repeat with consent that is already expired, revoked or otherwise inactive to check idempotency and appropriate error handling.
After revocation, attempt the access paths that the consent previously allowed. Test account and transaction reads, requests for accounts outside the original scope, and token refresh where relevant. Confirm that unauthorised requests fail according to the API contract and return no protected data. Also check that unrelated consents and permissions remain usable.
Where the product supports revoking only part of a consent, verify that the removed permission is blocked while retained permissions continue to work. For a payment initiation flow, distinguish withdrawal of ongoing access from cancellation of a payment already submitted. The expected treatment of an in-flight payment depends on its processing state and applicable requirements, so test it against the documented payment lifecycle.
Practical API test example
Assume a test consent grants read access to account A and transaction history. The example below describes assertions rather than prescribing a particular endpoint or response code:
- Obtain consent and confirm that an authorised request can read account A.
- Revoke the consent through the supported customer journey and confirm the recorded state is revoked.
- Retry the read with the existing access token, then try to refresh the token.
- Assert that neither request returns protected data and that the response matches the API contract.
- Confirm that a separate consent for account B still works.
Repeat the access attempt immediately after revocation and after any documented propagation interval. If behaviour differs across the gateway and resource API, investigate stale caches or delayed state synchronisation rather than treating the revocation response as sufficient evidence.
Check failure modes and evidence
Include negative tests for a failed revocation request, duplicate requests, an unavailable consent service and delayed event delivery. Verify that the customer is not shown a successful revocation while access remains authorised. If processing is asynchronous, check that retries do not restore access or create conflicting consent states.
Retain evidence linking the test to the consent identifier, action time, resulting state and resource API outcome. Avoid storing live credentials or unnecessary customer data in logs. Treat deletion or retention of data previously retrieved by a provider as a separate requirement: revocation stops future authorised access, while handling existing copies depends on applicable rules and the product’s data-retention obligations.
Frequently asked questions
How should tests handle a revocation request that times out?
Treat the outcome as unknown until the consent state and resource access are checked. Query the authoritative consent state where supported, retry safely according to the API contract, and verify that a retry cannot create conflicting states or restore access.
Should a revocation test check that the third-party provider deletes previously retrieved data?
Test deletion separately from access revocation. Revocation concerns future authorised access; deletion of data already retrieved depends on applicable requirements, the provider’s obligations and the product’s retention rules.
What evidence is useful for an audit of revocation testing?
Keep the test case and expected behaviour, a non-sensitive consent reference, timestamps for the action and observed state, and the resource API results showing access was blocked. Redact tokens and avoid recording unnecessary personal data.
How can teams test revocation when the third-party provider is unavailable?
Use a controlled provider simulator to exercise consent and token interactions, then run integration checks when the provider environment is available. Document which assertions rely on simulation and verify the real integration’s contract and state synchronisation separately.