MultiIntegration
Three ways to start accepting payments
Pick the one that matches who writes your code. The payment itself is the same; what differs is how much of it lives on your side.
Payment page
The customer pays on our page and comes back. Card data never touches your servers.
Direct API
Your own checkout, your own design. You take on full PCI scope for it.
CMS module
A shop on a ready platform. Install, paste the keys, done.
What suits you
| Payment page | Direct API | CMS module | |
|---|---|---|---|
| Who it is for | Anyone who would rather not handle cards | Your own checkout, your own design | A shop on a ready platform |
| Where the customer pays | On our page, then returns to you | On your page | On our page, opened by the module |
| Card data on your servers | Never | Yes, in full | Never |
| PCI scope | Minimal, SAQ A | Full, SAQ D | Minimal, SAQ A |
| Time to first payment | A day | A sprint | An hour |
PCI is the part most people underestimate. A hosted page keeps card data out of your servers entirely, which is why it costs a merchant less to run, not just less to build.
From the application to the first live payment
What we need from you
- A registered company and a Georgian bank account
- A site or an app with a description of what you sell
- A developer for a day, or a platform we already have a module for
- An address to receive callbacks, reachable from the internet
Questions we get asked before the first payment
How long does it take to connect?
A ready module is about an hour, the payment page about a day of a developer’s work, your own checkout on the API about a sprint. Sandbox keys are issued before anything is signed, so you can start on the day you apply.
Do we need PCI DSS?
On the payment page card data never reaches your servers, so your scope stays at the smallest form there is. On the direct API the card form is yours, and the full scope comes with it. That one row decides the way in for most merchants.
Can we try it without a contract?
Yes. Test keys, the base address and the specification with field names and error codes come with the application. Nothing is charged in the sandbox and no money moves.
The customer came back to our returnUrl. Is the order paid?
No. The return only means the browser came back. Proof is the status: take the callback, verify the signature, read the payment once more and only then release the goods.
What if the callback does not arrive?
Delivery is retried while your address is unreachable or answers an error. Either way, read the payment by its identifier: the status we answer with is the source of truth, and the callback is only the nudge to go and read it.
Which currencies and methods are there?
GEL, USD and EUR by agreement. On the page: Georgian and international cards, Apple Pay, Google Pay and QR. The exact set for your account is fixed in the contract.
Can a payment be refunded?
Yes, in full or in part, with one request. The payment moves to the refunded status and a callback tells you about it, the same way a successful payment does.
What does it take to switch to live mode?
A signed contract, a callback address on HTTPS reachable from the internet, and the go-live checklist passed. The keys change, the code does not.