ქართული
English
The Payze alternative for Georgian merchants — and how to migrate
If you built on Payze and need somewhere else to process payments, this page is the practical version of that decision: what actually changes, what your developer has to rewrite, and where QuickPay genuinely won't cover what you had.
QuickPay is a Georgian payment aggregator. One integration connects you to Bank of Georgia, TBC, Credo, Liberty, Flitt, UniPay, Keepz, CityPay, Moka, Fastoo, PayPal, Paysera and more — cards, installments, BNPL, QR, crypto, bank transfer and cash on delivery. You keep your own merchant accounts with the banks. Money settles to you directly.
Most migrations are a day or two of developer time. Some aren't possible at all, and we say which below.
The single most important difference is the business model, not the API.
- Payze operated as a payment facilitator. Your payments ran under their master merchant relationship. QuickPay is an aggregator — you hold your own merchant agreement with each bank, and QuickPay sits between your code and their APIs. [VERIFY: confirm Payze's PayFac model against their merchant agreement — this shapes the whole page]
- You'll need bank merchant accounts. If you were relying on Payze's facilitator status to avoid opening your own, that's the real work of this migration — not the code. Onboarding with BOG or TBC typically takes days, not hours.
- Funds settle directly to you on your bank's normal schedule. QuickPay never holds your money.
- The integration surface changes, but the shape is familiar: create a payment, redirect the customer, handle a webhook.
| Payze | QuickPay | |
|---|---|---|
| Model | Payment facilitator [VERIFY] | Aggregator — you hold the bank relationship |
| Who holds the merchant account | Payze [VERIFY] | You, with each bank |
| Card payments | Yes | Yes — Visa, Mastercard, Amex, Apple Pay, Google Pay |
| Georgian installments (განვადება) | [VERIFY] | BOG, TBC, Credo, Flitt — 3–36 months, paid to you upfront |
| BNPL / 0% (გადანაწილება) | [VERIFY] | BOG, Flitt |
| Crypto | No | CityPay — settles to you in GEL |
| QR payments | Yes | Yes |
| Recurring / subscriptions | Yes | Yes — stored card tokens |
| Split payments for marketplaces | Yes — core product | No |
| Hosted checkout | [VERIFY] | Yes |
| Payment links | Yes (email payments) | Yes |
| E-commerce plugins | [VERIFY] | WooCommerce, OpenCart, PrestaShop, CS-Cart, WHMCS, Easy Digital Downloads |
| SDKs | [VERIFY] | PHP, Laravel, Node/TypeScript |
| Pricing model | [VERIFY] | Per-module subscription. No percentage of sales. |
Before you start
You need three things: an active merchant account with at least one Georgian bank, a QuickPay account with that bank's credentials entered, and an API key. Keys are brand-scoped and come in two forms — qpk_test_... for sandbox and qpk_live_... for production. Test keys only work while the brand is in test mode, so there's no way to accidentally charge a real card from a test run.
Mapping the concepts
Three pieces of your Payze integration need to move. Everything else is usually untouched.
1. Charge creation → POST /v1/payments
Wherever your code creates a Payze charge, it now posts to https://api.quickpay.ge/v1/payments with a Bearer token. The response contains a payment_url. Redirect the customer there.
POST https://api.quickpay.ge/v1/payments
Authorization: Bearer qpk_live_...
Idempotency-Key: order-10432
Content-Type: application/json
{
"amount": 149.99,
"currency": "GEL",
"gateway_slug": "bog_card",
"merchant_order_id": "ORDER-10432",
"description": "Order #10432",
"customer_name": "Nini Beridze",
"customer_email": "[email protected]",
"customer_phone": "+995555123456",
"return_url": "https://yourstore.ge/thank-you",
"cancel_url": "https://yourstore.ge/cart",
"webhook_url": "https://yourstore.ge/webhooks/quickpay"
}Only amount is required. Everything else above is optional — shown here because most real migrations need it: return_url/cancel_url are where the customer lands after paying or cancelling, webhook_url overrides your brand-level webhook endpoint for this one payment, merchant_order_id is your own order reference, and the three customer_* fields prefill the checkout.
One behaviour worth knowing: gateway_slug is optional. Omit it and the customer chooses their own payment method on QuickPay's hosted checkout — card, installment, BNPL, crypto, bank transfer. If Payze had you building your own method selector, you can delete it.
Amounts are decimals, not minor units. 149.99, not 14999. This trips up almost every migration. GEL is the default; USD, EUR and GBP are supported.
The Idempotency-Key header prevents double-charges on retry. Replaying the same key returns 200 with the original payment. Replaying it with a different amount or currency returns 409.
2. Status polling → webhooks
If your Payze integration polled for status, stop. QuickPay pushes.
Events: payment.paid, payment.failed, payment.refunded, payment.partially_refunded, payment.refund_pending, payment.cancelled, payment.expired, plus subscription.charged, subscription.failed, invoice.paid and lead.submitted.
Each request carries a signature header:
QUICKPAY-SIGNATURE: t=1754300000,v1=8f3a...v1 is HMAC-SHA256 over the string "{timestamp}.{raw_json_body}", keyed with your webhook secret:
[$t, $v1] = parse_signature($_SERVER['HTTP_QUICKPAY_SIGNATURE']);
if (abs(time() - $t) > 300) {
return response('stale', 400); // 5-minute skew limit
}
$expected = hash_hmac('sha256', "{$t}.{$rawBody}", $webhookSecret);
if (!hash_equals($expected, $v1)) {
return response('bad signature', 400);
}Sign against the raw request body, before any JSON parsing or re-encoding. Re-serialising the payload changes the bytes and the signature will never match — this is the most common webhook bug in any HMAC scheme.
Your endpoint must return a 2xx within 30 seconds. Failures retry up to 5 times, so handlers must be idempotent — you will occasionally receive the same event twice.
3. Refunds → POST /v1/payments/{uuid}/refund
Full or partial. Omit amount to refund the remaining balance. Returns the updated payment object. Note that refunds can land in a payment.refund_pending state before completing, depending on the gateway — handle both events.
Testing
Put your brand in test mode, use your qpk_test_... key, and run the flow end to end. No real gateway calls are made. The dashboard includes an API Playground for firing requests without writing code, which is the fastest way to confirm your payload shape before touching your application.
Go-live checklist
- Bank merchant credentials entered and the module activated
- Sandbox run completed for every payment method you intend to offer
- Webhook endpoint deployed, signature verification tested against a real payload
- Handler confirmed idempotent — replay the same event twice
- Timestamp skew check in place
- Switch the brand out of test mode and swap
qpk_test_forqpk_live_ - One live transaction at minimum value, then refund it
- Old Payze webhook endpoint left running for a week to catch stragglers
You may not need one. If you run a store on WooCommerce, OpenCart, PrestaShop, CS-Cart, WHMCS or Easy Digital Downloads, there's a plugin — install it, paste an API key, choose your payment methods. Setup is typically under an hour, and the WooCommerce plugin covers installments, BNPL, refunds and stock sync.
If you sold through Payze without a website at all, payment links replace that directly: create a link, send it by Instagram, WhatsApp, SMS or email, and the customer pays on a hosted page. For in-person sales, QR payments do the same from a printed code — no POS terminal, no rental contract.
Being direct about this saves you a wasted week.
- No split payments. If you ran a marketplace on Payze and split a single charge between multiple recipients, QuickPay cannot replace that. It was Payze's core product and we don't have an equivalent. Look at a payment facilitator, not an aggregator.
- We are not an acquirer and don't hold funds. You need your own merchant agreement with each bank. QuickPay routes and reconciles; the bank processes and settles.
- We don't remove bank onboarding. Approval, documentation and rates are between you and the bank. We'll help you pick the right one, but we can't approve you.
- Not every gateway supports every feature. Installments, BNPL and recurring vary by provider — check the module list before committing to a method.
Do I need a registered company to use QuickPay?
That depends on your bank, not on us. Several Georgian banks open merchant accounts for individual entrepreneurs. QuickPay itself has no business-entity requirement for registration or platform use — the constraint comes from whichever bank you're onboarding with.
How long does migrating from Payze take?
If you already hold bank merchant credentials, most API migrations are one to two days of developer work: swap the charge call, replace polling with a webhook handler, retest. If you need to open bank merchant accounts first, that's the longer pole — usually several days to a couple of weeks, depending on the bank.
Can I keep my existing bank relationship?
Yes, and you should. QuickPay connects to your existing merchant account rather than replacing it. If you're with Bank of Georgia, you keep your BOG rates and settlement schedule and add QuickPay in front of it.
Does QuickPay take a percentage of my sales?
No. You pay a per-module subscription for the payment methods you activate. Bank processing fees are separate and go to the bank as they always did. Every module has a free tier.
Can I offer installments the way Payze customers asked for?
Yes — BOG, TBC, Credo and Flitt installments are supported, 3 to 36 months. You receive the full amount upfront and the bank collects from the customer. BNPL at 0% is available through BOG and Flitt, with the bank absorbing the financing cost.
What happens to payments that were in flight on Payze?
Those settle under your Payze agreement and aren't affected by adding QuickPay. Run both integrations in parallel during the switchover and keep your old webhook endpoint alive for a week or so afterwards. [VERIFY: confirm current Payze settlement behaviour before publishing this answer.]
Is there a sandbox?
Yes. Test keys (qpk_test_...) work while your brand is in test mode and make no real gateway calls. The dashboard also includes an API Playground for testing requests without writing code.
Start migrating
Create a free account, enter your bank credentials, and run a sandbox payment — no card required to sign up. If you'd rather talk it through first, tell us what you were running on Payze and we'll map it to what's available.