Original and parent
Both, not one. A partial refund of a partial refund still resolves to the sale it came from.
T-NET / Gateway
Three channels. One transaction record.
TANTRA PAYGATE 3.0 is the channel-facing half: separate documented REST surfaces for POS, QR and e-commerce, validated against a configuration cache before a single byte reaches the switch.
7.1 · Functional specification
The modules.
| Module | Specification |
|---|---|
| Channel APIs | Separate, documented REST surfaces for POS, QR and e-commerce over TLS with JWT authentication, OTP where required, rate limiting and request signing; OpenAPI specification and Postman collections issued as companion volumes. |
| Transaction operations | Sale, void, partial refund, full refund and reversal, selected by the operation type on the request and validated against the original transaction. Every derived transaction carries the original and parent transaction references, the relationship type, the original and cumulative refunded amounts and the settlement timestamp — so the history of a sale is reconstructible end to end. |
| Validation | Institution, aggregator, merchant, store, terminal, capability, currency and fee-plan validation against a Redis configuration cache loaded from the core database at start-up and refreshed on a five-minute cycle and on change; validation failures are returned with a specific reason code before any switch traffic is generated. |
| Transaction identifiers | Retrieval reference number, authorisation code and system trace audit number are generated and stored for every transaction and carried into clearing, settlement and dispute handling. |
| MDR, fee & commission | Merchant discount rate and fee calculation per merchant, channel, card type and currency, including aggregator commission, applied at authorisation and carried into settlement. |
| Batch & settlement services | Terminal batch close with totals reconciliation, batch detail retrieval, pending-settlement query and settlement processing; transaction filter service for operations and support. |
| E-commerce checkout | Checkout session and payment-link generation, hosted payment page, direct payment confirmation API and status query; callback and return-URL handling for the merchant's site. |
| QR services | EMVCo QR decoding and validation, Secure Point verification, device-binding checks and QR settlement records. |
Lineage
A refund knows what it refunded.
This is the unglamorous part that decides whether a dispute takes ten minutes or a week. Every derived transaction points back at its original and its parent, and carries the running total of what has already been returned.
Typed, not inferred
Void, partial refund, full refund or reversal — recorded as a relationship rather than guessed from amounts.
Original and cumulative
The original amount and the cumulative refunded amount, so the third partial refund that would exceed the sale is declined.
Settlement timestamp
Carried on the record, so a transaction can be placed in the right settlement window without a join.
Validation
Declined at the edge, with a reason.
What gets checked before the wire
- Institution and aggregator — is this entity licensed and active
- Merchant and store — status, KYC state, permitted channels
- Terminal — capability profile, activation and attestation state
- Currency — is this terminal provisioned for the transaction currency
- Fee plan — is a rate card in effect for this merchant, channel, card type and currency
Why it lives in a cache
Reading five entity records from a database on the authorisation path is a latency budget nobody can afford. The configuration cache is loaded from the core database at start-up and refreshed on a five-minute cycle and on change — so a merchant suspended in the back office stops transacting in seconds, not at the next restart.
- Store
- Redis
- Load
- from core DB at start-up
- Refresh
- 5-minute cycle + on change
- Failure mode
- specific reason code, no switch traffic
MDR and fees
Calculated at authorisation, carried into settlement.
The fee that applies is resolved from the merchant, the channel, the card type and the currency together, with aggregator commission on top where an aggregator introduced the merchant. It is computed once, at authorisation, and travels with the transaction.
| Input | Comes from | Effect |
|---|---|---|
| Merchant | MyMercho Suite rate card | The base MDR and fee plan in effect on the transaction date |
| Channel | The API surface used | POS, QR and e-commerce can carry different rates |
| Card type | BIN and product lookup | Debit, credit and commercial can be priced separately |
| Currency | Transaction currency | Rates are held per currency, not converted at fee time |
| Aggregator | Merchant hierarchy | Commission applied where an aggregator introduced the merchant |
Rate cards are configured and approved in My Mercho Suite 2.0 under maker-checker, with effective dates. The gateway applies whichever card is in effect when the transaction occurs.
Next step
Send us your message spec. We will send back a profile.
Your scheme endpoint, your CBS interface and your terminal mix are enough for us to come back with an ISO 8583 packaging profile, a sizing note and a certification schedule.