Payments
Paying KRAGOS
A quote becomes a link, the link becomes one payment, and the payment becomes a tax invoice with the same reference your bank statement carries.
Nothing on this page can take a payment
The Pay control below is a disabled button. There is no form, no gateway address in any link, and no route on this site that could reach a payment provider.
It is drawn this way because of what the rail itself says. KRAGOS's payment rail is built and held: the container is deployed and serving, and it is bound to the InstaPay sandbox gateway. The guard in the rail refuses to print a payment link on any document while that is true, so no live payment link exists to put here.
When the rail is released, this page becomes the real thing and this banner comes off. Until then kragos.ai claims no online checkout: a quote is paid by EFT to the banking details printed on the invoice.
1. How a payment reaches you
KRAGOS is a business-to-business, quote-based supplier. There is no cart and no product list, because nothing we sell has a shelf price: every job is quoted. So a payment is never something you find; it is something we send you, against a quote you already have.
A payment link names exactly one payment. If your quote is split into a deposit and a balance, or into milestones, each part gets its own link, its own amount and its own reference. The link is single use and expires.
- Request
You ask for a quote on the request form. No payment is possible at this point and none is offered.
- Quote
We price the work and issue a quote: line items, VAT at 15%, a total, and a payment schedule: one payment, or a deposit and a balance, or milestones. The split is set per quote; there is no fixed percentage rule.
The schedule must add up to the total exactly. A schedule that does not sum is refused when it is set, not discovered later.
- Link
Each entry on the schedule becomes its own payment request, carrying one amount, one unique merchant reference such as
ECO-Q0041-DEP, and one link with a 256-bit random token that expires after 30 days.The link is emailed to the named person on the quote. We never publish it, and we cannot show it to you again, because only the hash of the token is stored, so a lost link is replaced, never recovered.
- Pay
You open the link and see the page below: what is due, what it is for, the whole quote for context, and one button. Pressing it takes you to InstaPay.
Your browser never sends an amount. The token names one payment request and the server already holds what it is worth, so there is no amount, quantity or line to tamper with.
- Confirm
InstaPay tells our server, server to server, that the payment completed, and signs that message. That signed notification is the only thing that marks anything paid. Your browser returning to our site proves nothing and is treated as display only.
- Invoice
A tax invoice is issued per payment, so a deposit and a balance each get their own number. The number is derived from the merchant reference, so
ECO-Q0041-DEPbecomesINV-ECO-Q0041-DEP, and one payment can only ever produce one invoice, however many times the gateway retries its notification.
2. The payment page
This is the page a payer lands on, drawn from the rail's own layout. It is the deposit on a R45,000 HELM implementation: R45,000 excluding VAT, VAT at 15%, and a 40% deposit with the balance on go-live.
Everything on it is derived on our server from the stored payment request. The only thing the browser sent was the token in the address bar.
Ecopackaging (Pty) Ltd t/a KRAGOS
QUO-2026-0041
| HELM implementation, standard template x1 | R 45 000.00 |
| VAT at 15% | R 6 750.00 |
| Quote total incl VAT | R 51 750.00 |
Payment schedule
| Deposit, 40%, due now | R 20 700.00 |
| Balance on go-live | R 31 050.00 |
You will be taken to InstaPay to pay. Card details are entered on their secure page and never reach us.
What the real button does, and why it is off here
On the live rail the button is the submit control of an HTML form that posts to webpay-v2.omnea.co.za. That form carries the merchant identifiers, the amount, the reference, the notify and return addresses, and an MD5 checksum. It carries no card field of any kind, because there is none to carry.
On this page it is a <button disabled> with no form around it. Nothing is posted anywhere.
The rail serving today posts to webpay-v2-sbox.omnea.co.za, the sandbox gateway. That single difference is the whole of what “held” means.
3. The reference on your bank statement
The reference is the one string that ties an invoice to a line on a bank statement, so it is built for the person reading that statement at month end, not for a machine. It is never a random identifier.
ECO-Q0041-DEP reads as: ECO, our routing code with the merchant provider, then the quote, quote 41, then which part of it, the deposit. Thirteen characters, legible at a glance.
How to read it
| Segment | Means | Values |
|---|---|---|
| ECO | Our routing code with the merchant provider. It is ours, it never changes, and the provider requires it to be the first three characters. | ECO, always |
| Q0041 | The quote this payment belongs to. | Q0000 to Q9999 |
| DEP | Which part of the schedule is being paid. | DEP deposit · BAL balance · FUL a single full payment · M01 to M99 milestones |
| 2, when present | The re-issue number. If a link expires and we send a fresh one, the new one carries the next number. A spent reference is never used twice. | ECO-Q0041-DEP → ECO-Q0041-DEP2 |
On your statement. The reference is what we ask the provider to carry through to the payment. Whether it reaches the printed bank statement on both sides is a question still outstanding with the provider, and it is named as outstanding rather than promised here.
| Date | Description | Amount |
|---|---|---|
| 2026-09-05 | ECO-Q0041-DEP | R 20 700.00 |
And the tax invoice for that payment is INV-ECO-Q0041-DEP. The invoice number and the statement line are one key, on purpose: reconciliation is then a person matching two identical strings, not a person guessing.
4. Card details never reach us
KRAGOS never sees, receives or stores a card number. Not the number, not the expiry, not the security code, not the cardholder's name as entered on a card.
The provider's checkout form has no field for any of them. The only payer fields it accepts are a name, a surname, an email address and a mobile number, and we send only the name and email that are already on your quote. When you press Pay you leave our site and the payment is handled entirely by the provider.
What we send, and what we hold
| Handled by | |
|---|---|
| Card number, expiry, security code, 3-D Secure step | The payment provider and your bank, on their own pages. Never KRAGOS. |
| The amount, the reference, the merchant identifiers, the checksum | KRAGOS, computed on our server from the stored payment request. |
| Your name and email address, as they appear on the quote | KRAGOS, and passed to the provider so the payment can be identified. |
| The signed notification that a payment completed, and the payment method used | The provider sends it; KRAGOS verifies and stores it verbatim. |
We keep every notification we receive, accepted or refused, exactly as it arrived. That log is what answers the question that actually gets asked, which is “I paid, what happened?”.
5. No third-party code on the page
Nothing on this site or in this proof carries a payment provider's script, pixel, iframe or font. The payment page is a page of our own that posts a form outward when the payer presses the button. Between quote and button press there is no third-party code on the page at all.
For what personal information the payment rail processes, and where it goes, see clause 19 of the Privacy Notice. For the terms that govern paying an invoice, see clause 7 of the Terms of Service.
6. Where this rail actually stands
Status, stated with its evidence
Built and held. The payment container is deployed and answering on its own hostname. It is bound to the provider's sandbox gateway, which is a separate account from the live one, so no real money can move through it.
There is a standing instruction from the owner that the rail is not to be deployed to production until an exact, digest-pinned release package with a synthetic-transaction proof, a rollback rehearsal and a stated financial compensation boundary is put in front of him. That package has not been assembled, and the release of the held deploy has not been made.
So this page is designed, rendered and inert. It is ready for the day the release happens and it claims nothing before then.
This page cannot take a payment. It explains how paying KRAGOS works; it is not the payment surface itself, and no payment provider is contacted by anything on it. Published by Ecopackaging (Pty) Ltd (registration number 2014/032538/07, VAT registration number 4530265216) trading as KRAGOS, 750 Nieuwhout Street, Garsfontein, Pretoria, 0081, South Africa. Enquiries to ops@kragos.app.
