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

Feature	Description
Open Banking PSD2 payment	SEPA transfer initiated from the payer's bank, no card, no traditional payment gateway
Multiple operations per flow	A single POST/flow/v1/flows can create several operations with independent URLs
Multiple recipients	Each operation can be linked to a recipient with name, email and phone number
Hosted payment page	Zertiban provides a fully managed and customizable payment UI
Bank-grade SCA	The payer authorizes directly in their usual online banking
Real-time webhooks	OPERATION_OPENED, OPERATION_COMPLETED, OPERATION_REJECTED, OPERATION_EXPIRED events
Reconciliation by externalId	Business 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

{
  "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

• Authentication: OAuth2 Client Credentials and token lifecycle
• Getting started: Onboarding, businessUuid and credentials
• Flows and operations: Structure, states and data model
• Webhooks: Real-time events and HMAC signature
• PagaFactu: Invoice collection with PDF and appended page
• Environments: Sandbox and production