Testing Guide

Testing your integration in the sandbox environment is essential before going live with Blink Data.

Sandbox Environment

Sandbox URL: https://sandbox.data.blinkpay.co.nz

The sandbox environment provides:

• Full API functionality with mock bank (PNZ)
• Simulated data access flows
• All consent flows supported (Gateway, Redirect, Decoupled)

Limitations:

• Mock data only (not real customer data)
• PNZ is the only bank (see Sandbox and Production Banks)
• Some bank-specific behaviours simplified

Getting Sandbox Credentials

Sandbox credentials are provisioned when you sign up at merchants.blinkpay.co.nz. If Settings > API Settings shows no sandbox key, select Request Sandbox API Key there. See Getting API Credentials.

Sandbox and Production Banks

In the sandbox, test every flow with PNZ, the test bank; it supports every data type, including statements. The production banks (ANZ, ASB, BNZ, Westpac, Kiwibank and NZHL) are used in production, with their bank values, decoupled identifiers and statement availability listed on the Bank Coverage page. GET /v1/meta lists the banks enabled for your organisation in the environment you are calling. The bank value is case-sensitive; an unrecognised value is rejected with 400 (see Error Codes).

Try the Demo

To see the Data API in action before building your integration, visit our demo site:

ACME Loans Demo: https://acme-loans-dev.blinkpay.co.nz

This demonstrates the full data consent and retrieval experience.

Sandbox Test Values

The sandbox has one test bank, PNZ: Payments NZ's API Centre test bank, and the only bank shown in the Gateway. Use these values for every flow:

Test Scenarios

1. Happy Path - Redirect Flow

Objective: Verify end-to-end data access using Redirect Flow

Steps:

1. Create consent with redirect flow (PNZ bank)
2. Redirect user to bank URL
3. Complete authentication with user01 / password
4. Handle redirect back to your application
5. Verify consent status is Authorised
6. Retrieve accounts list
7. Retrieve balances for each account
8. Retrieve transactions for an account

Expected Results:

• Consent status: Authorised
• Account data returned successfully
• Redirect back to your application

2. Happy Path - Decoupled Flow

Objective: Verify data access using Decoupled Flow

Steps:

1. Create consent with decoupled flow (PNZ bank, +64-259531933)
2. Poll the consent status every 5 seconds
3. Verify consent status is Authorised
4. Retrieve account data

Expected Results:

• The consent is authorised automatically; only +64-259531933 does this, and any other number stays AwaitingAuthorisation until the window ends
• Account data retrieved successfully

3. Error Handling - Timeout

Objective: Verify timeout handling

Steps:

1. Create consent with redirect flow
2. Do not complete the bank authorisation
3. Wait out the bank's authorisation window (up to 10 minutes covers every bank)
4. Retrieve the consent and verify its status has changed to Rejected
5. Handle the timeout gracefully in your application

Expected Results:

• Consent status: Rejected
• Application shows appropriate error message

4. Error Handling - Rejection

Objective: Verify rejection handling

Steps:

1. Create consent with redirect flow
2. Redirect to bank
3. Choose Cancel on the PNZ login page, before logging in
4. Handle redirect back with rejection status
5. Verify consent status is Rejected

Expected Results:

• Consent status: Rejected
• Application handles rejection gracefully

5. Error Handling - Revocation

Objective: Verify revoked consent handling

Steps:

1. Create and authorise a consent (the auto-approve number is quickest)
2. Retrieve some account data successfully
3. Revoke the consent via DELETE /v1/consents/{consent_id} (204)
4. Attempt to retrieve account data again
5. Verify you receive 403 with code BDT410
6. Handle the revoked consent gracefully

Expected Results:

• Data retrieval fails with 403 BDT410 after revocation, and revoking the consent again returns 409 BDT702
• Application detects revoked consent and prompts for new authorisation

6. Pagination Testing

Objective: Verify pagination implementation

Steps:

1. Create and authorise a consent
2. Retrieve transactions with size=10
3. Iterate through multiple pages using returned pagination values
4. Verify pagination metadata is correct
5. Test edge cases (last page, page beyond total)

Expected Results:

• All pages retrieved correctly
• Pagination metadata accurate
• Edge cases handled gracefully

Producing Sandbox Errors

To test your error handling, you can deliberately produce each failure state:

For automated tests, drive each state yourself: authorise a consent with the auto-approve number and revoke it with DELETE /v1/consents/{consent_id} to exercise your Revoked handling, and choose Cancel on the PNZ login page for Rejected. Handle the remaining outcomes, such as expiry or a bank error, from the documented consent statuses and error codes.

Next Steps

• Going Live - Production checklist when testing is complete