Transaction infrastructure

Connect payments, verification, billing and transactions in one platform.

Most payment problems are not payment problems. They are reconciliation problems — three systems holding three versions of the same transaction. ScanPay keeps one record and lets every service read from it.

Transaction record
Transaction
SPV-8F2A41C9
Origin
Website checkout
Collection
Complete
Verification
Verified
Billing entry
Posted
Webhook delivered
200 OK

One reference, read by every service that touched the transaction.

Platform architecture

What sits where.

Collection methods on top, the shared transaction layer in the middle, business workflows underneath.

Collection
Payment GatewayWebsite, app and business-system payments
M-Pesa STK PushPrompt-to-pay on the customer's phone
BillingISP, electricity, water and gas invoices
Shared transaction layer
ScanPay transaction recordOne reference, one status, one history — written by every service above and read by every workflow below.
Confirmation & workflows
Payment VerificationConfirm details before completing a transaction
EscrowHold and release on agreed terms
API & WebhooksPush transaction events into your systems
Dashboard & RecordsOperational view and transaction history
Transaction lifecycle

One transaction, end to end.

Step 01

Initiated

A payment is created by a checkout, an app, or a billing run.

OriginWebsite checkout
Step 02

Processed

The payment moves through the gateway and the method used to collect it.

MethodM-Pesa
Step 03

Verified

Details are confirmed and the shared transaction record is updated.

Status Verified
Step 04

Distributed

Webhooks notify your systems, and billing or escrow act on the same record.

Delivery200 OK
Connectivity

One integration, more services over time.

Start with the service you need now. Adding another later does not mean a second integration, a second reconciliation process, or a second source of truth.

  • Same authentication across gateway, verification and billing
  • Same reference format across every service
  • Same webhook contract for every transaction event
transaction-events.js
// Every service writes to the same transaction
scanpay.webhooks.on("transaction.verified", (e) => {
  console.log(e.reference, e.source);
  // -> SPV-8F2A41C9  "gateway"
  // -> SPB-2E4471DA  "billing"
  // -> SPE-3C90F72E  "escrow"
});

// And the same lookup works for all of them
await scanpay.transactions.get("SPV-8F2A41C9");
Business workflows

What the platform makes possible.

Sell and release

Collect the payment, verify it, and release the order from the same record.

Bill and activate

Generate the invoice, take the payment, verify it, update the account.

Hold and complete

Structure a transaction between two parties and complete it on agreed terms.

Reconcile once

Match your ledger against one reference instead of three separate exports.

Questions

Transaction infrastructure FAQs.

It is the layer that connects payment collection, payment verification, escrow and billing so they share one API, one set of webhooks and one transaction record.

When collection, verification and billing each keep their own records, reconciliation becomes guesswork. A shared reference means your finance team, your support team and your systems are reading the same thing.

Yes. Businesses commonly start with one service — often M-Pesa collection or payment verification — and connect others later without changing how they integrate.

Yes. A REST API covers initiating payments, requesting verification and querying transaction status, and webhooks push transaction events to your systems as they change.

Build on ScanPay transaction infrastructure.

One API, one transaction record, and room to add services as your operation grows.