# Accepting bank transfer payments on your website

> Integrating bank transfer payment into an online store: buyer journey, invoice creation via API, confirmation webhook and mistakes to avoid.

Source : https://virement.tn/en/blog/accept-bank-transfer-payments-on-your-website — last updated : 2026-09-19

On an online store, card payment goes through a gateway that answers “paid” or “declined” within seconds. A bank transfer works differently: it is made by the buyer in their bank, after the order. Here is how to integrate it safely.

## What changes compared with the card

- **No hosted payment page, no redirect.** The buyer stays on your site.
- **No immediate “paid” response.** The API call that creates the invoice answers that the order is *committed*.
- **Confirmation arrives later**, by webhook, when the buyer's bank confirms the transfer.

In other words: the order is released only on that webhook.

## The journey in five steps

1. **The buyer chooses “pay with virement.tn”** on your payment page.
2. **Your form asks for two fields**: their phone number and their validation code (6 characters, single-use, valid for 24 h, available in their virement.tn space). This code replaces entering a card number: it proves consent.
3. **Your server creates the invoice** through the API, authenticating the call with your key in the `X-Api-Key` header. The response indicates that the invoice is confirmed: the order is committed.
4. **The buyer makes the transfer** from their bank's app, to your verified RIB.
5. **The bank confirms, virement.tn sends the signed webhook** to your server. This is the signal to release the order.

## What you need before starting

- An active virement.tn **merchant account**.
- A **verified RIB**: without it, invoice creation is refused.
- An **API key**, generated from Settings → API keys (Manager role required). The key and the webhook signing secret are displayed only once: keep them on the server side.

## Mistakes to avoid

- **Releasing the order on the API response.** This is the most serious mistake: the transfer has not happened yet.
- **Calling the API from the browser.** Your API key must stay on your server.
- **Not verifying the webhook signature.** Without that, anyone can fake a confirmation.
- **Not making processing idempotent.** As a precaution, make sure receiving the same confirmation twice breaks nothing (releasing an already released order must have no effect).
- **Forgetting the “never paid” case.** Plan for expiry or cancellation of orders awaiting a transfer.

## Why offer bank transfer in addition to the card

- **No card fees.**
- **No card data** to handle or protect.
- A natural option for customers who prefer not to enter their card online.

You don't have to choose: bank transfer can complement the card. Our comparison of [bank transfer, card or direct debit](/en/blog/bank-transfer-card-or-direct-debit) helps you decide according to your sales.

## To go further

The [integration page](/en/api-integration) summarizes the principle. The full technical reference — endpoints, formats, sandbox environment — is provided directly to partners during integration.

## Frequently asked questions

### When should you release an order paid by bank transfer?

When the confirmation webhook is received, never on the response to the invoice-creation call. At the end of that call, the order is committed but not yet paid.

### Does the buyer have to enter a card number?

No. They provide their phone number and a validation code found in their virement.tn space, then pay by bank transfer from their bank.

### How long does a validation code stay valid?

24 hours. It is single-use.
