Security and trust | ISP Billing Pay

Credentials with clear boundaries

Merchant and device keys come from cryptographically secure random bytes and are stored as SHA-256 hashes on the gateway. Revoke or rotate a lost phone's key without replacing every listener's credentials.

Merchant endpoints scope payments, intents and devices to the authenticated merchant. Initial onboarding challenges the configured webhook. Reissuing existing merchant credentials requires its current API key and a successful challenge.

Payment events use HMAC SHA-256 over the delivery timestamp and raw body. Your server verifies the signature with a constant-time comparison, rejects stale signatures and records each event ID once. See the exact verification example.

Production webhook destinations use public HTTPS. Outbound delivery validates destination addresses, disables redirects and verifies TLS. Keep local-development exceptions disabled on live deployments.

Protect the payment and its destination

Situation	How it is handled
A receipt is forwarded again	A unique merchant, provider, receiving-account and transaction-ID combination prevents a second payment record.
Two customers send the same amount	Different transaction IDs remain separate. Automatic matching requires the payer number.
Several accounts could receive a payment	Conflicting references are held for review instead of choosing the newest account.
A receipt cannot be fully read	It is preserved for review, without automatically creating a matched credit.
A payment is reversed	A recognized reversal blocks activation. If it arrives before the credit, its transaction identity is retained; the later credit stays reversed and produces a reversal event.
A webhook arrives again	It keeps its event ID. Your application deduplicates delivery and credits each payment once.

Claims refer to payments already received and check payer, amount, currency and association. A code cannot create money, override a reversal or move a payment assigned to another reference. A name alone does not prove ownership.

Your account controls still matter. A typed number and public name are not independent identity verification. Apply additional verification to disputed claims, device recovery and conflicting account requests.

A deliberate trust boundary

What a forwarded receipt proves

The dedicated phone forwards messages from configured mobile money senders. The Android app filters senders before queueing a message; the server validates the sender and parses recognized payment details.

A listener submission is not a bank-signed receipt.

A device key proves the caller holds that credential. It does not cryptographically prove network origin, final settlement or ownership of the receiving account. Sender filtering and parsing reduce mistakes; they do not make spoofing or a compromised phone impossible.

Use a dedicated, locked phone under your control. Restrict installations and physical access, protect the SIM, keep Android updated and rotate the key if the device may be compromised. Add only sender aliases validated against actual receipts.

Uganda and Ghana have built-in sender lists. Custom sender setup is available for other networks and countries allowed by the deployment, without payment-provider API keys. Adding a sender only permits its messages to be considered; it does not verify their origin or guarantee support for their language and layout. Validate real receipts and their extracted fields before enabling automatic activation.

Reconcile records with your receiving mobile money account. Set review thresholds appropriate to the service delivered. Automatic access is a business decision based on this notification channel and your controls, not a guarantee against every dispute.

Keep payment data purposeful

The Android manifest requests incoming SMS, internet, connectivity, notifications, boot restart and foreground/background-operation permissions. It does not request access to browse the existing SMS inbox, contacts, location, microphone or camera.

Messages outside the configured sender list are discarded by the app. Accepted messages queue locally while offline; the local body is deleted after server acknowledgement. Acknowledgement means the submission was handled, not that the customer was connected.

The gateway stores payment details and accepted payment messages for reconciliation. They can contain payer names, numbers and account balances. Device diagnostics include last contact and IP address. Treat these records as sensitive and restrict staff access.

The current implementation does not provide automatic retention expiry or application-level encryption of all stored payment data. Operators must set retention rules, secure databases and backups, configure appropriate encryption and provide their operation's privacy notice. Read the data-handling overview.

Reliable operations complete the system

The phone queues captured messages during an internet outage. The gateway stores outgoing events and schedules retries. Delivery depends on a working SIM, phone, server and retry worker; these mechanisms do not promise instant or uninterrupted delivery.

Gateway operator

Maintain HTTPS, updates, restricted administration, protected secrets, backups, retry workers, monitoring and recovery procedures.

Merchant integration

Verify events, protect accounts, credit payments once, reconcile receipts and handle reversals, refunds and customer support.

Track receipt, association and activation separately. A paid package can still fail at router login. After verifying the customer and session state, recover access using the paid username and remaining entitlement.

These controls are implementation features, not claims of independent certification, regulatory approval or payment-network endorsement. Validate your deployment and receiving-account permissions before launch.

Work with us

Report a security concern

Email contact@ispbillingpay.com or contact your deployment administrator. Include the affected route, time, sanitized event ID and reproduction steps. Do not include customer receipts or full credentials in your first message.

Revoke or rotate an exposed listener key immediately. If merchant credentials may be exposed, involve the gateway operator and reconcile recent assignments before resuming automated access.

Open the support guide Read the API documentation

Trust is built into
the payment journey.

Money goes to you.

A key for each role.

More than an amount.