Trinol Payment

Status

Release candidate. Every planned phase — from the database and tenant isolation through device pairing, matching, the ledger, webhooks, the SDK and merchant plugins — is implemented and validated in automated tests. A production capacity run and the approvals for live use remain. Until those are granted, live ingestion stays switched off and test applications run on a simulator. No results are published yet.

Context

In Bangladesh many businesses take payment into a personal mobile-wallet account rather than through a payment gateway. The money arrives, but nothing tells the business which order it was for. Someone checks each payment against each order by hand — slowly, and with every chance of confirming the same payment twice or missing one entirely.

Problem

Confirming a payment is a matching problem with money attached. The system has to decide which single order a payment belongs to, confirm it exactly once even when two requests race, and hold anything ambiguous for a person to decide rather than guessing.

Constraints

• It observes payments on the merchant's own authorised Android device. It does not connect to or impersonate an official provider API, and it says so — it never claims provider-server verification it does not have.
• The device sends normalised facts only: provider, amount, masked sender digits, transaction reference and time. Never OTPs, PINs, passwords, contacts, message history or private app data.
• One transaction can create one payment, and one order can have one confirmed payment — enforced by the database, not by hoping two requests never collide.
• Many businesses on one platform, each isolated from the others.

Approach

Every confirmation — automatic or through the merchant's API — goes through one shared consume service. A transaction moves from AVAILABLE to RESERVED with a short-lived reservation, then to CONSUMED when the payment is created. A consumed transaction cannot be used again, and an expired reservation releases it for a fresh check.

Automatic confirmation needs exactly one eligible order with the same amount, receiver, sender, provider, reference and payment window. Several candidates, a wrong amount or a late observation open a reconciliation case instead, with a stable reason code, for an operator to resolve.

System architecture

The Android companion signs what it observes. Signed ingestion rejects replays and duplicates, then runs the deterministic matcher in the same database transaction that stores the observation. Confirmation creates the payment, the match record, the ledger entry, the audit record and an outbox event together. A worker delivers that event to the merchant as a webhook.

Security and reliability

Row locks and unique indexes enforce one active reservation per transaction, one payment per provider transaction and one confirmed payment per order. Race tests run parallel verification, parallel confirmation, and the automatic matcher against the public API, on independent database connections.

The ledger is append-only: a database trigger rejects updates and deletes from normal application connections. That is database enforcement, and the documentation says exactly that rather than calling it cryptographic tamper evidence.

API keys are stored only as digests and are scoped to one organisation, application and environment. Webhooks are signed with HMAC-SHA256 over a timestamp and the exact body, carry no raw device messages, and are retried on a fixed schedule from thirty seconds to twenty-four hours.

Implementation

A hosted checkout, an operations dashboard and a reconciliation workspace; the Android companion; a scoped developer API with a test simulator and API logs; a server-side SDK with examples; and merchant packages for PHP, Laravel, WordPress and WooCommerce.

Next steps

Complete the production capacity run and the approvals for live use — provider policy, Android permissions and distribution, authorised samples and physical-device tests — then switch on live ingestion for the first merchants.