Developer Docs

ZertiPay: Features ​

Open Banking PSD2 payments, create a flow, get a URL per operation and deliver it to the payer.

ZertiPay is Zertiban's product for collecting payments via Open Banking PSD2. It lets you create payment flows with one or several operations and obtain a URL per operation to deliver to the payer.

Zertiban handles the entire payment experience, from bank selection to SCA authorization, while your system receives real-time notifications via webhooks when the operation completes.

For the shared concepts of flows and operations, structure, states and transitions, see Flows and operations.

ZertiPay features ​

FeatureDescription
Open Banking PSD2 paymentSEPA transfer initiated from the payer's bank, no card, no traditional payment gateway
Multiple operations per flowA single POST/flow/v1/flows can create several operations with independent URLs
Multiple recipientsEach operation can be linked to a recipient with name, email and phone number
Hosted payment pageZertiban provides a fully managed and customizable payment UI
Bank-grade SCAThe payer authorizes directly in their usual online banking
Real-time webhooksOPERATION_OPENED, OPERATION_COMPLETED, OPERATION_REJECTED, OPERATION_EXPIRED events
Reconciliation by externalIdBusiness identifiers travel through the entire flow and appear in every webhook

ZertiPay: end-to-end payment flow ​

1. Backend: Get the token (OAuth2) ​

Before any operation, the backend obtains an access_token via OAuth2 Client Credentials.

POST /idp/oauth2/token
  • The token has a short lifetime (~300s)
  • It must be cached and renewed before expiry
  • It is used in every API call

2. Backend: Create the payment flow ​

The backend creates a flow by sending a multipart/form-data with a JSON payload.

POST /flow/v1/flows

Zertiban synchronously returns:

  • flowUuid
  • operations[].url

Always store each operation's uuid

Your system must persist operations[].uuid, since it is the internal identifier used for:

  • status queries,
  • cancellations,
  • event history,
  • technical reconciliation with the webhook system.

3. Backend / Frontend: Deliver the URL to the payer ​

The URL from operations[].url redirects the payer to Zertiban's hosted payment page. The customer's system is responsible for delivering it via:

  • Email
  • Push notification
  • Its own UI

When the URL is opened, the operation transitions to OPENED.

CREATED → OPENED

4. Bank: Authorization (SCA) ​

The payer:

  • selects their bank on Zertiban's page,
  • is redirected to their online banking,
  • authorizes the payment via SCA.

No additional apps or hardware required.

5. Zertiban: Confirmation webhook ​

When the bank confirms the operation, Zertiban updates the status to COMPLETED and sends a webhook to your endpoint.

OPENED → COMPLETED

POST https://yourapp.com/webhooks/zertiban
json
{
  "eventType": "OPERATION_COMPLETED",
  "resource": {
    "externalId": "OP-2026-001",
    "status": "COMPLETED"
  }
}

6. Backend: Reconciliation ​

The backend uses resource.externalId to:

  • locate the operation,
  • update the payment status,
  • reconcile with the internal system (ERP, billing, etc.).

System behavior ​

  • Flow creation is synchronous
  • Payment URLs are returned in the API response
  • operations[].uuid must always be stored for full traceability
  • There are no callbacks during flow creation
  • Webhooks are used for state changes

Customer responsibility ​

Zertiban does not send communications to the payer. The customer is responsible for:

  • distributing the payment URL,
  • managing the notification experience,
  • persisting identifiers (externalId and operationUuid) for reconciliation,
  • integrating the status into their system.

Next steps ​