Transaction · Payment session
The transaction API describes the lifecycle and status of every payment processed through the viaBanking platform, not the customer's bank statement. The merchant application creates a payment session, reads the intermediate and final callbacks, and gets a clean signal when the funds have actually been credited to the C2B account.
Scope
The second list is the more important one on this page. It rules out expectations that come from other "transaction API" products in the market.
Covers
Does not cover
Lifecycle
Each transition names the party that performs it. The platform routes and normalises; regulated actions belong to the licensed provider and the customer's bank.
Merchant
The merchant application posts a create-session request to the transaction API with the payment amount, the currency and the target bank.
Platform
The platform routes the session to a licensed PIS provider that reaches the target bank in that market. No regulated action happens here, only routing.
Bank + licensed PIS
The user's payment consent flow runs on the user's account-issuing bank; SCA is hosted and verified by that bank. The licensed PIS provider orchestrates the flow.
Licensed PIS
The licensed PIS provider returns a confirmation that the user completed the flow and funds have been debited from the user's bank. This is an intermediate status inside the transaction lifecycle.
Platform + account provider
The platform confirms, via the account provider's API in read-only mode, that funds have actually been credited to the merchant's C2B account.
Platform
The final status of the transaction is written to the transaction API and delivered to the merchant application through a signed callback.
Core idea
When the licensed PIS provider returns a confirmation, it means the user completed the payment flow and funds have been debited from the user's bank. It does not mean that funds have already arrived at the merchant's C2B account. Between the two events sit clearing, correspondent bank hops and, depending on the bank's setup, a window where the user could still revoke the payment consent.
The transaction API surfaces both events. The intermediate status tells the merchant application that the flow was completed. The final status tells the merchant application that the credit has actually landed on the C2B account, confirmed by the platform via the account provider's API in read-only mode.
No legal claim about irrevocability is made here. The behaviour is described as a mechanical fact: two events, two callbacks, one release decision on the merchant side.
Callbacks
Two callbacks per payment session, two different merchant actions. The merchant decides when to release value; the transaction API supplies the signals.
Intermediate callback
What: Sent when the licensed PIS provider confirms the user completed the flow.
Merchant action: Update the merchant record; do not release the order or the account balance yet.
Reading this callback as final is the single most common risk in an open banking checkout.
Final callback
What: Sent when the platform has verified the credit into the merchant's C2B account.
Merchant action: Release the order, credit the wallet, or move on to the next step in the merchant workflow.
The merchant decides when to release value; the platform provides the signal.
Visibility
The transaction API exposes the current status of every payment session, plus the history of all status transitions with timestamps and event ids.
Each callback payload is stored end to end. The merchant application can re-read the callback content for reconciliation or replay through the transaction API.
Structured logs for every request, retry and provider response are available. The logs are a resource the merchant's finance and compliance teams can query.
FAQ
No. The transaction API describes payment sessions inside the viaBanking platform. It does not read the customer's bank statement, balances or history. There is no AIS product in the current phase.
It means the user completed the flow and funds have been debited from the user's account. It is an intermediate status. The final status is the credit into the merchant's C2B account, confirmed by the platform via the account provider's API in read-only mode.
The merchant. The transaction API delivers the intermediate and the final callbacks; the release decision belongs to the merchant application. Releasing on an intermediate callback carries risk on the merchant side.
Yes. Structured request logs, callback payloads and status transitions are available through the transaction API. The logs are a resource the merchant's compliance team can query. viaBanking does not provide compliance-as-a-service.
There are situations where the user can revoke the payment consent before funds leave the bank; it depends on the bank's setup. Once the funds have moved, revocation of the payment consent stops applying.
Talk to sales about wiring the transaction API into a live checkout. For the wider connectivity story, see the bank API gateway. For the merchant-first read, see open banking solutions.
viaBanking is a software and technology provider. Regulated payment initiation and account information services are delivered by licensed partner institutions. viaBanking does not hold an AIS or PIS licence, does not execute bank payments and does not move funds.
