MultiIntegration
Four operations
A payment integration is smaller than it looks. These four cover it; everything else is the detail of one of them.
Operations
| POST /payments | Create a payment and get the link to the payment page |
| GET /payments/{id} | Read the payment: status, amount, method, timestamps |
| POST /payments/{id}/refund | Refund, in full or in part |
| POST your callbackUrl | We notify you of a status change, signed |
The base address of the sandbox and of the live gateway is issued together with your keys. The examples below use $MP_API_BASE for it.
Creating a payment
| amount | String, two decimals. The customer is charged exactly this. |
|---|---|
| currency | GEL, USD or EUR, by agreement |
| orderId | Your order number. Unique on your side, we return it in every answer. |
| description | What the customer sees on the page |
| callbackUrl | Where we send the status. HTTPS, reachable from the internet. |
| returnUrl | Where the customer goes after the page |
Statuses
| created | The page exists, nobody has paid yet |
|---|---|
| pending | The payment is with the bank, the answer has not arrived |
| paid | Money captured. Only now release the goods. |
| failed | Refused. The reason comes with it. |
| expired | The page ran out of time, nothing was charged |
| refunded | Returned, fully or partly |
Two rules that save the most time
- The customer coming back to your returnUrl is not proof of payment. It only means the browser came back. Proof is the status you read from us.
- Never trust an amount that came from the browser. Create the payment on your server, from your own order.
The full specification
Exact field names, every error code, the callback signature scheme and the test cards come with sandbox access, so that what you read always matches what the gateway actually answers.