Key terms used in BlinkPay documentation and open banking, grouped by the product they apply to: terms used by both Blink Payments and Blink Data first, then terms specific to each product.
A technical integration bridge between the services provided by Banks, BlinkPay and your application. An API defines the kinds of calls or requests that can be made, how to make them, the data formats that should be used, the conventions to follow, etc.
The verification that a user is valid.
The rights and permissions that an authenticated user is allowed to access, based on an access policy.
A financial institution that is authorised to perform monetary transactions and provide financial and other services to its Customers.
An optional callback_url on a decoupled flow consent, on both products. BlinkPay sends it an unsigned GET with the consent ID as cid (GET <callback_url>?cid=<consent_id>) when the customer authorises, the bank rejects the consent or the authorisation window ends. It carries no status: fetch the consent to read the outcome. It can arrive more than once, or not at all. Blink Data: the URL must be publicly resolvable, and use HTTPS in production.
A consent status meaning the consented action is complete; what that is depends on the product. Blink Payments: a single consent or quick payment is Consumed once the bank has made its final decision on the payment, which includes a payment the bank rejected after accepting it, so Consumed does not mean paid: read the payment's status. An enduring consent becomes Consumed once its expiry has passed. Blink Data: the consent's period has ended, because its expiration_date_time has passed. Data can no longer be read with it; create a new consent.
A person, organisation or entity that holds an account with a Bank and authorises a consent for your application: to make a payment (Blink Payments) or to share their account data (Blink Data).
A workflow to gather consent from an Online Banking Customer typically using a mobile device. The customer can authorise on a different device or at a different time from their interaction with your application.
A consent flow that takes the Customer through a BlinkPay gateway to choose their bank and complete their consent (and, for Blink Payments, the payment). It simplifies integration by handling bank selection and flow type selection. Blink Payments only: the Gateway is the only flow that supports card payments.
The date your integration goes into production and can be used by your customers.
A lightweight data-interchange format commonly used for communication between web systems.
A 4-digit code that classifies a business's type. Blink Payments: assigned by the acquirer bank, used by card networks for transaction routing and reporting, and required for card payment onboarding. Blink Data: a transaction's merchant.category carries the MCC of the business the customer paid, where the bank supplies it.
The industry-standard protocol for Authorisation. BlinkPay uses OAuth 2.0 with the client_credentials grant type.
The desktop and mobile internet banking experiences provided by Banks to Customers.
The framework of APIs administered by Payments NZ and implemented by New Zealand Banks which enable access to underlying Bank functionality, e.g., data and payments.
Data that could be used to identify an individual person (e.g., name, address) and as otherwise defined by personal information in the Privacy Act 2020.
Repeatedly reading a consent or payment until it reaches the status you are waiting for. Poll only once the customer has returned or the callback has fired, every second; in the direct decoupled flow with no callback, every 5 seconds. Blink Payments: poll a payment every second until it is AcceptedSettlementCompleted or Rejected, for a minute or two at most, then leave it to a periodic wash-up. Stop at a terminal state.
A workflow to gather consent from an Online Banking Customer typically using a web browser. The customer is redirected from your application to the Bank for authentication, then redirected back upon completion. It works on mobile too, where the bank's website or app opens.
An architectural style of HTTP web services, exposing uniform operations.
A common standard for encoding of characters, supporting many character types.
The bank that processes and settles card transactions on your behalf (e.g. BNZ, ASB). Required for card payment onboarding.
15-character alphanumeric identifier assigned by your acquirer bank to uniquely identify your business for card payment settlement. Required for card payment onboarding.
A card transaction type where the physical card is not presented at point of sale — applicable to all online/e-commerce card payments.
An electronic transfer of funds through the "Bulk Electronic Clearing System" (BECS) administered by Payments NZ. The payment is initiated by or on behalf of the payer, which sends funds directly into the bank account of the payee.
A consent type that allows a Merchant to debit funds from an Online Banking Customer on an ongoing basis, subject to agreed parameters such as maximum amounts and periods, which the Merchant sets and the Customer approves at their Bank.
A single occurrence of a Fixed Recurring Payment (FRP) schedule firing on a specific date — analogous to one individual debit on the 1st of the month under a direct debit mandate. Many FPEs exist per FRP. Each FPE is tracked independently with its own status, retries, and webhook events, and links to the payment it created.
The schedule that automatically initiates fixed-amount payments against an authorised enduring consent at a regular cadence — analogous to a direct debit mandate. The FRP holds the amount, start date, next payment date, retry strategy and status; its frequency comes from the consent's period, and it ends when it is cancelled or the consent is revoked or expires. Each scheduled execution against it is a Fixed Payment Execution (FPE).
An organisation, person or entity that provides goods and/or services to Customers and receives payments in respect of those goods and/or services.
A payment made only once by a Customer to a Merchant. Uses a Single Consent or Quick Payment.
The 16-digit number on a credit or debit card. In card payments, PAN entry refers to the customer manually entering their card number, expiry, and CVV.
A single consent and its payment created in one call. In the redirect or gateway flow, retrieving it after the customer returns completes the payment; in the decoupled flow, BlinkPay submits the payment as soon as the customer authorises. A quick payment has at most one payment.
A series of payments made by a Customer to a Merchant at a regular schedule. Uses an Enduring Payment Consent.
Passing a payment fee on to the customer by adding a surcharge to the amount they pay. BlinkPay enables it per account on request.
A series of variable-amount Recurring Payments where the payment amount may differ each period within the limits of the Enduring Consent.
A signed event BlinkPay sends to an endpoint you subscribe to. Webhooks are sent only for Fixed Recurring Payment events (a scheduled payment completed or failed, or the schedule cancelled). There are no webhooks for quick, single or enduring payments, or for consent status changes: poll for those. Blink Data has no webhooks.
Blink Data error codes, of the form BDTnnn (for example BDT410), returned in the code field of the error body alongside timestamp, path, status, error and message. Branch on the HTTP status and code. Some 400 errors, such as a malformed body or a missing required field, have no code; read message for those. Blink Payments uses its own BP codes.
The customer's permission, given at their bank, for your application to read data from the accounts they choose to share. You create it with POST /v1/consents, naming the permissions you need and optionally an expiration_date_time and the start_date_time/end_date_time window of data it covers. Once Authorised, it can be used for repeated data calls until it is Consumed or Revoked.
A terminal consent status: a gateway consent was abandoned before the customer chose a bank, and the 15-minute bank-selection window ended. Create a new consent.
The account holder whose data you read. GET /v1/party returns the customer who authorised the consent, and GET /v1/accounts/{account_id}/party the holder of a specific account. Needs the ReadParty permission.
A data type a Blink Data consent lets you read: ReadAccounts, ReadBalances, ReadTransactions, ReadStatements or ReadParty. The customer approves the permissions at their bank. A data call the consent has no permission for returns 403 BDT411, and a permission the bank doesn't offer (such as ReadStatements at Kiwibank) is rejected with 400 BDT241 when you create the consent. Permissions belong to the consent; scopes belong to your API client.
A terminal consent status: the consent has been cancelled, either by you (DELETE /v1/consents/{consent_id}) or by the customer at their bank. Data calls with it return 403 BDT410 (or BDT415 when it was revoked at the bank).
A statement the bank has issued for an account and period. You can list an account's statements, retrieve one, and download its file (PDF or plain text, depending on the bank). Available at ANZ, ASB, BNZ and Westpac (and PNZ in the sandbox), not at Kiwibank or NZHL. Needs the ReadStatements permission.