How it works

One payment, from the checkout to your account.

What your customer does, what your system sends and gets back, where the money actually goes, and what happens when it does not work. Written for the person who has to explain this to a colleague.

The journey

Five stages, from two sides.

The left column is your customer. The right column is your system. Neither has to know much about the other.

The stages of a Banky payment, showing what the payer does and what the merchant’s system does at each
Stage	Your customer	Your system
At your checkout	Chooses Banky, then chooses how to pay from the methods you have enabled for their country.	You initiate a payment request against the API. The response carries the payment's status from the outset.
Choosing the method	Picks a bank transfer, a card, a wallet or a local method. On a bank transfer they also pick their country and their bank.	Nothing. Which methods appear is configuration held against your merchant account, per country — not logic you write or maintain.
Authorising	Confirms the payment. On a bank transfer that means logging into their own online banking and approving the amount there, under whatever their bank requires of them.	Waits. The recipient details and the reference travel with the payment, so there is no manual entry for the payer and nothing for you to match up afterwards.
Back on your site	Sees a confirmation message once the payment is completed, and can verify its status on their own side.	Has the payment's status. Under model ② you can also look it up in the merchant portal.
Settlement	Nothing further.	Depends on your model — straight to your own bank account, or held by Banky and settled to you on an agreed schedule.

Where the money goes

Two paths, and you choose which.

This is the one structural decision on the platform, and it changes what settlement, refunds and payouts each mean for you.

Straight to your bank account

Purchase
Merchant

Banky initiates a payment from the payer's bank account to your bank account. The money goes where it was always going and Banky never holds it.

Held by Banky, settled to you

Purchase
Banky
Merchant

Banky initiates payments from the payer's account, then securely holds the funds before settling them to your account. Payouts, settlements and refunds are fully supported.

The two models, compared row by row

Data

What is collected, and what never is.

What the payer gives Banky

On a bank transfer, the choice of bank and their authorisation inside their own banking session. Banky does not see or hold their banking credentials — the login happens at their bank, not here.

What Banky never asks for

A registration. There is no payer account on this platform, which means there are no payer credentials here to be lost. On bank-transfer payments there is no card number in the flow either.

How it is protected

Personal information is encrypted and protected by industry standard banking security. Instant bank transfers are built on top of core banks' KYC procedures, so identity was established by a regulated institution before the payment began.

When it fails

Four ways a payment does not complete.

Every payments page documents the happy path. If you are comparing us to something you already run, you have had the other one — so here it is, with what your customer sees in each case.

Four reasons a payment does not complete, and what each side sees
Cause	What the payer sees	What you can do
Not enough balance	A message during the payment process. The most common reason a payment does not complete.	Nothing to fix on your side — the customer can retry with another account or another method.
A technical issue mid-payment	Usually a message while executing the payment, at the point it fails.	The API response carries the status. If it is not clear what happened, support can trace it.
No online banking	They cannot complete an instant bank transfer at all — the mechanism is a transfer authorised by logging in.	This is why the other methods are there. A customer without online banking pays by card, wallet or a local method instead.
A recipient account sent when overwrite is disallowed	Nothing — this fails before the payer is involved.	The request errors. There is a per-merchant setting that allows or disallows overwriting the saved recipient account; if it is off and you send one anyway, that is the result.

See it working Ask us something specific