Skip to content

Bank Redirect (Interac & Open Banking)

Overview

Bank Redirect lets you accept payments made directly from a customer's bank account. You select the payment method on your platform and the gateway returns a redirect URL to a PSP-hosted page where the customer signs in to their bank and approves the payment.

Payment method type Description
interac-redirect Payment through the Interac network, where the customer approves the transfer in their Canadian bank's online banking
openbanking-redirect Account-to-account payment initiation, where the customer authorizes the payment in their own bank

Both are alternative payment methods. Unlike Wallet Redirect, there is no card involved at any point — no PAN, no card network, and no 3-D Secure step. The customer authenticates with their bank, and the bank's approval is the authorization.

Availability depends on your PSP and the customer's country

Interac is a Canadian interbank network, so interac-redirect is only usable for customers banking in Canada. Open Banking coverage depends on which banks your PSP supports in the customer's country. Ask your account manager which of the two are available on your terminal.

Integration Methods

Bank Redirect is available through all three integration types:

Method Effort Notes
Hosted Payment Page None Interac / Open Banking appear automatically on the HPP once enabled on your terminal
Embedded Fields Minimal The gateway exposes a stub script (interac-redirect / openbanking-redirect) that registers a factory; your page renders its own "Pay" button
API Integration Low Initiate a payment on a terminal enabled for TRX_TYPE_PAYMENT and follow the returned redirect

Activation Prerequisites

Before accepting Bank Redirect payments:

  1. Request activation of interac-redirect and/or openbanking-redirect on your terminal from your account manager.
  2. Your PSP must have the corresponding product provisioned on your account, with an acquiring connection behind it. No bank credentials, API keys, or consent flows are required on your side — the PSP owns the connection to the customer's bank.

Hosted Payment Page

If you are already integrated with the Hosted Payment Page, no additional development is required.

Once the methods are enabled on your terminal, they appear as payment options on the HPP alongside cards and other APMs. After the customer selects one, the HPP redirects them to the PSP-hosted bank selection and login page.

sequenceDiagram
    participant Customer
    participant Merchant Frontend
    participant Payment Gateway
    participant PSP
    participant Bank

    Customer->>Merchant Frontend: Start checkout
    Merchant Frontend->>Payment Gateway: Create HPP session
    Payment Gateway-->>Merchant Frontend: HPP URL
    Merchant Frontend->>Customer: Redirect to HPP
    Customer->>Payment Gateway: View HPP and select Interac / Open Banking
    Payment Gateway->>PSP: Initiate bank redirect
    PSP-->>Payment Gateway: Redirect URL
    Payment Gateway-->>Customer: Redirect to PSP bank page
    Customer->>Bank: Sign in and approve the payment
    Bank-->>PSP: Approval
    PSP-->>Payment Gateway: Notify payment result
    Payment Gateway-->>Merchant Frontend: Notify result (webhook + return URL)

API Integration

Both methods run on the payment transaction type, not the card one. That has two consequences for a Direct API integration:

  • The terminal must carry the TRX_TYPE_PAYMENT feature. A terminal enabled only for card purchases cannot process them.
  • They are initiated through the Payments endpoint, POST /api/transactions/payment, not through /api/transactions/authorize. There is no transaction_type field to set — it is always PAYMENT — and no payment_method object, because no card or account data is collected.

See Payments – Direct API Integration for the full request and response contract, including the required return_url, error_url, cancel_url and customer_ip fields.

Selecting the method

The method field on the payment endpoint currently accepts OPEN_BANKING, UPI, WALLETS, BANK_TRANSFER and QR_CODE. Interac and Open Banking Redirect are selected by the customer on the Hosted Payment Page or by your own checkout through Embedded Fields, where the payment method type is chosen directly. Ask your account manager which route applies to your terminal.

Response

The payment response is asynchronous and carries a redirect:

{
  "result": {
    "id": "PyTxAbCdEfGhIjKlMnOp",
    "terminal_id": "TERM001",
    "reference": "PAY-20260331-001",
    "currency": "EUR",
    "amount": 10000,
    "transaction_type": "PAYMENT",
    "status": "PENDING",
    "approved": false,
    "pending": true,
    "errors": []
  },
  "redirect": {
    "transaction_id": "PyTxAbCdEfGhIjKlMnOp",
    "url": "https://psp.example.com/payment/form/init/..."
  }
}

Redirect the customer's browser to redirect.url. After they approve the payment at their bank, they are returned to one of the URLs you supplied (return_url, error_url, or cancel_url) and the gateway emits the standard transaction-processed webhook with the final status.

The transaction stays PENDING until the bank confirms

The initial response is always PENDING — it only means the redirect was created. Bank approval is asynchronous and can take noticeably longer than a card authorization. Treat the transaction-processed webhook as the source of truth and never release goods on the redirect alone.

A transaction that the customer abandons is not cancelled automatically. Bank journeys can outlast any timeout that would be safe to apply, and cancelling is not reversible — a late approval arriving after a cancellation would be dropped and leave you short a settled payment. Such a transaction therefore stays PENDING until the bank actually reports an outcome, which for an abandoned payment may be never. Use the Transaction Status API to check where one stands rather than assuming it will resolve itself.

Flow Diagram

sequenceDiagram
    participant Customer
    participant Merchant Frontend
    participant Merchant Backend
    participant Payment Gateway
    participant PSP
    participant Bank

    Customer->>Merchant Frontend: Choose Interac / Open Banking
    Merchant Frontend->>Merchant Backend: Place order
    Merchant Backend->>Payment Gateway: POST /api/transactions/payment
    Payment Gateway->>PSP: Initiate bank session
    PSP-->>Payment Gateway: Redirect URL
    Payment Gateway-->>Merchant Backend: redirect.url
    Merchant Backend-->>Merchant Frontend: redirect.url
    Merchant Frontend->>Customer: Redirect to PSP
    Customer->>Bank: Sign in and approve the payment
    Bank-->>PSP: Approval
    PSP-->>Payment Gateway: Final result
    PSP-->>Customer: Redirect to return_url / error_url / cancel_url
    Payment Gateway-->>Merchant Backend: Transaction-processed webhook

Embedded Fields

For Embedded Fields, the gateway exposes a small stub script for each method that registers a factory on window:

Method Script key
interac-redirect window['interac-redirect'].factory
openbanking-redirect window['openbanking-redirect'].factory

The script does not render a bank selector and does not perform the redirect. Your embedded checkout renders its own "Pay" button; when the customer clicks it, the backend authorize response carries the redirect_url and the embedded checkout host performs the navigation.

Limitations

  • Payment transaction type only. These run as PAYMENT transactions. The funds move as a single transfer, so there is no hold to capture or void later and AUTHORIZE-then-capture is not available.
  • No stored payment method. Nothing is tokenized and nothing can be reused — every payment sends the customer to their bank again. Recurring and one-click flows are not supported.
  • No 3-D Secure. The customer's bank performs its own strong customer authentication; the gateway runs no 3DS step and returns no ECI or CAVV.
  • Asynchronous outcome. The result arrives by webhook after the customer approves at their bank, not in the authorize response — and an abandoned payment may never produce one, leaving the transaction PENDING.