BOG and TBC Online Payment Integration for Georgia WebsitesBOG and TBC Online Payment Integration for Georgia Websites

Paying “by bank transfer” for an online store or a service booking often means losing orders. If you want the customer to pay on the spot, you need a payment system on the website—using the most common routes in Georgia: Bank of Georgia (BOG) or TBC, with 3D Secure and proper status handling.

1) Why a bank transfer isn’t enough—and what it costs you

A bank transfer works when order volume is small and manual processing is manageable. But as soon as online payments become a daily thing, three practical problems show up:

• Customers drop off mid-process. After placing the order, they have to open an app/online banking, find the IBAN, enter the purpose of payment. Many people want “right now,” not “I’ll transfer it later.”
• You can’t automate statuses. Receiving a transfer doesn’t mean your system knows the order is “paid.” You end up marking things manually, checking SMS/bank statements, fixing mistakes.
• Disputes are harder to manage. When a customer says “I paid,” you start hunting for proof. With card payments, the bank response and transaction ID are already part of the flow.

If you sell a product/service where the decision is impulsive (tickets, courses, clothing, beauty services), integrating online payments often directly increases completed orders—simply because there are fewer steps.

2) What you need before you start—legal entity, bank account, merchant application

Both BOG integration and TBC integration start not with code, but with “paperwork and access.” The minimum list looks like this:

1. A legal entity or sole proprietor. The bank needs a real business to register the merchant account to.
2. A bank account at the same bank or an agreed settlement account. You need to decide upfront where the money should land.
3. A merchant (acquiring) application. This is the contract for accepting card payments. It also defines:
   • commission model ([to be filled])
   • payout frequency/schedule ([to be filled])
   • what types of payments you need: one-time, recurring, pre-authorization, etc. (if needed)

Practical tip: before filling out the application, write down your scenarios. For example: “online store, delivery in Tbilisi/regions, order cancellation and refunds possible within X hours.” This helps the bank set the right parameters—and helps you avoid midstream changes.

3) How the flow works in simple terms: order → redirect to bank page → 3D Secure → callback → status confirmation

For the business, the flow should feel simple, but technically there are two sides: what the customer sees and what happens on the server.

A typical scenario:

1. Order on the website. The customer fills the cart/form and clicks “Pay.”
2. Redirect to the bank page. The site creates a payment initiation and the customer is sent to the bank’s secure page (or a bank window, depending on the scheme).
3. 3D Secure. The customer confirms the payment (SMS/app/biometrics—whatever the bank supports).
4. Callback (server-to-server notification). After the payment finishes, the bank sends a message to your server: what actually happened.
5. Status confirmation. In your system, the order gets the correct status: paid / failed / pending / canceled (the exact names depend on your system).

Important detail: returning the customer to a “Thank you” page is good for UX, but the payment must be recorded definitively via the callback. Otherwise you’ll have cases where:

• the customer closed the browser and never returned to the “Thank you” page, but the payment succeeded;
• the customer saw the “Thank you” page from cache/refresh, but the payment actually failed;
• a network issue happened and, relying on frontend only, you marked the order incorrectly.

This is where a “payment system on the website” stops being just a button and becomes proper business logic.

4) BOG and TBC—what’s different in practice, what we choose, and why

Both banks work in real life, and both can handle online store payments. The differences show up more “in practice”:

• Onboarding and communication. Who answers faster, how easily you get a test environment/access, how clear the documentation is. This often matters more than “which API is better.”
• Additional methods. For some businesses, Apple Pay/Google Pay is critical; for others, installments. Sometimes one bank sets this up smoothly, while the other requires more coordination. Details depend on each bank’s offering and can change.
• Financial terms. Commission, payout schedule, refund terms—there’s no single “right” answer. You should compare against your average basket size and margin.

What do we choose in practice? The short answer: we choose what disrupts your process the least. If you already have an account at one bank, your accounting is set up, and operations run there, it often makes sense to start there. If a specific feature is critical to you (e.g., installments or a particular payment method), your choice follows that.

At Weblier, when we build an online store or an order system, both BOG integration and TBC integration are planned the same way: first the status logic and back-office process (how you process orders), then the bank side.

5) Cost—merchant commission and integration timeline

There are two types of “cost” you need to separate:

1. Merchant commission (to the bank).
   This is a percentage/fee per transaction and sometimes additional conditions. I can’t give exact numbers upfront—it depends on the business and your agreement. Placeholder section:

• Commission: [to be filled]
• Payout frequency/delay: [to be filled]
• Refund rules/timelines: [to be filled]

1. Integration work (on the website side).
   The timeline depends on what you already have ready:

• If the system is ready (cart, order flow, customer data, admin panel), integration often takes [to be filled] business days.
• If you don’t yet have order logic or statuses, adding payments becomes part of the overall build and the timeline increases to [to be filled].

The trade-off is straightforward: a “quick plug-in” might work, but if your statuses aren’t structured correctly (paid/pending/refunded), you’ll get chaos later around refunds, inventory, and delivery.

6) Common mistakes: incorrect callback handling, skipping test mode, relying on frontend-only payment status

These three mistakes are the most common when a “payment system on the website” is added in a rush.

• Incorrect callback handling.
  Problem: the system receives the notification but can’t match it to the right order (e.g., wrong order_id, duplicate notifications, or it doesn’t store the transaction ID).
  Practical approach: attach a unique identifier to each payment, write it to logs, and assume the callback may arrive more than once.
• Skipping test mode.
  Problem: you test for the first time “in production,” then discover failed payments aren’t recorded or pending gets stuck.
  Practical approach: in test mode, run at least these scenarios:
  • successful payment
  • failed payment
  • cancellation (customer closed it)
  • callback arrived, but the user didn’t return to the site
  • user returned, but the callback was delayed
• Relying on frontend-only payment status.
  Problem: the “Thank you” page is not proof. Sometimes the page opens but the payment didn’t finish; sometimes it’s the other way around.
  Practical approach: change the order status only on the server, based on the bank’s confirmed response. On the frontend, just show “We’re verifying your payment” and refresh the status from the API.

If you get these three right, everything else (design, copy, buttons) is secondary.

7) Installments and Apple/Google Pay—briefly

Two popular add-ons that often come “in the next phase,” but it’s better to account for them from day one.

• Installments.
  This usually isn’t “just another payment method.” It often requires an additional agreement, correct display of terms in the UI, and more statuses/confirmation logic in the flow. If your average basket size is high, installments can materially change conversion, but they increase operational questions (cancellation, refunds, partial refunds).
• Apple Pay / Google Pay.
  For the customer, it means fewer fields and faster checkout. For you, it’s part of the same acquiring setup, but it often adds extra requirements for domain verification and testing. The good news: if your base card payment flow is built correctly (callback, statuses, logs), add-ons tend to slot in more easily.

FAQ

Question 1: Do I absolutely need a legal entity to enable online payments?
In most cases—yes. The bank signs the merchant agreement with a business (LLC/sole proprietor). The bank will tell you about specific exceptions, but plan on registration being required.

Question 2: Can I have payments from two banks at the same time (BOG + TBC)?
Technically yes, but it only makes sense if you have a real reason: different terms, a backup channel, or a specific method available only through one of them. Otherwise UX gets more complicated and support effort doubles.

Question 3: When should I change the order status to “paid”?
Only when your server receives the bank’s confirmed response (callback/verification). A “success” message on the customer’s screen is not enough.

Question 4: How should I plan refunds?
Plan it from the start: who performs the refund (admin/manager), how you store the transaction ID, and how it reflects on the order (refunded, partially_refunded). Write the bank’s terms and timelines into [to be filled] so the team follows a single set of rules.

Start a project