TikiPay Refer and Earn Program

1. Payment automation in the Bangladesh business context

Bangladesh businesses often start with bKash, Nagad, Rocket or another familiar local method because customers already know how to pay. The operational problem starts after the customer sends money: which order does the payment belong to, is the amount correct, is the transaction real, and can the order be delivered without a person opening an app every time?

Payment automation separates collection from verification. Collection is the movement of money through the provider. Verification is the software decision that connects that payment to a specific order/session and proves the business can safely continue. TikiPay focuses on turning those payment events into a structured verification-first workflow.

2. The four layers: collect, detect, verify, fulfil

A reliable system can be understood as four layers. First, the customer pays. Second, a provider API, callback, transaction event or supported device bridge makes the payment visible to the automation layer. Third, the TikiPay/server workflow validates the event against the expected order. Fourth, the merchant application performs the business action.

Keeping these layers separate makes failures easier to handle. A payment can exist while the detection signal is delayed; a signal can arrive while the local order is missing; a valid payment can be verified while a downstream delivery service is temporarily unavailable. Each state should have its own recovery path.

3. Official merchant API vs personal/agent/payment-number automation

Official merchant API is the provider-approved server-to-server route for merchant accounts. It is appropriate when the business has the required merchant onboarding and wants formal API checkout/processing. The merchant phone does not need to be the payment bridge because the provider and servers communicate directly.

Personal, agent or payment-number automation is a different workflow. For supported MFS methods, TikiPay Direct can use a connected Android bridge that observes the payment SMS/notification signal and sends normalized event data to the TikiPay server. The server then matches the event to the pending order or submitted transaction information and returns a verification result.

4. Online and offline behaviour — what actually happens

If a customer sends money to a configured personal/agent/payment number while the connected Android handset temporarily has no internet, the provider can still deliver the payment to that MFS account. Mobile money transfer is handled by the provider network, not by the TikiPay website. An SMS may also reach the handset through the mobile network even when mobile data or Wi‑Fi is unavailable.

The TikiPay bridge can retain the supported event locally and synchronize it after internet connectivity returns, subject to Android permissions and background restrictions. Until the server receives and validates the event, the safest website state is pending. Once synchronized, the server can match amount, reference and order data and complete automatic verification. This is offline-capable payment capture and delayed sync; it should not be described as real-time server communication during a total network outage.

For official merchant API workflows, the merchant handset is not part of the verification path. As long as the provider and TikiPay/merchant servers are reachable, the payment workflow can continue even if the business owners personal phone is offline.

5. Why manual screenshot checking creates risk

Screenshots are easy for customers to send but weak as payment evidence. Images can be edited, reused or taken from a different transaction. Manual checking also creates queues: at night, during campaigns or when the owner is busy, paid customers wait for someone to open an app and compare details.

Automation should verify structured payment data rather than trust an image. The business can still keep a manual review path for exceptional cases, but the normal order should move only after server-side verification has confirmed the expected payment.

6. Order and invoice creation

Create a local order before the payment starts. Freeze the expected amount, currency/method context and customer-facing order reference. If TikiPay creates a hosted invoice/session, store its remote identifier against the local order before redirecting the customer.

A stable mapping is essential for reconciliation. Without it, support may know that money arrived but not which order should receive credit. Metadata or an internal reference should be unique enough to trace the business transaction without exposing sensitive customer data.

7. Customer payment experience

The checkout should tell the customer exactly how much to pay, which method or number is selected and what information must be submitted. Avoid making customers guess whether they should use Send Money, Payment or another provider action; show the instruction that matches the configured payment route.

After payment, show a verification state. If verification is immediate, continue to the paid/confirmed experience. If the event is delayed because of network or provider conditions, show pending and let the backend complete the process safely instead of asking the customer to resubmit repeatedly.

8. Verification rules that should never be skipped

A strong verification routine checks the remote status, expected amount, order/session mapping and transaction/reference uniqueness. Provider or payment-method information can be compared when available. If any required field does not match, the order should remain pending or move to review.

The server should be the authority. Browser success parameters, a customer screenshot or a frontend JavaScript variable cannot safely replace backend verification. This rule applies to ecommerce, SMM panels, bots, course sites, digital downloads and custom applications.

9. Duplicate transaction protection

One payment should not be able to fund two local orders. Store the normalized remote reference/transaction ID with a uniqueness rule or an equivalent idempotency guard. If a second order tries to use the same verified transaction, reject or flag it for review.

Callbacks can also be delivered more than once. The local fulfilment function must check whether the order has already been credited, delivered or activated before repeating the business action.

10. bKash, Nagad, Rocket and other MFS workflows

Each provider has its own customer wording and transaction format, but the business logic should be normalized: identify the pending order, accept the supported payment signal, parse the provider/reference/amount safely, send or receive the event through the TikiPay workflow, then run backend verification.

Do not assume every provider supports the same account type or API feature. Official merchant API availability, personal/agent rules and provider terms can differ. TikiPay configuration should expose only methods that are actually enabled for the merchant account or connected device.

11. Payment without a merchant account

A small business may begin before it has a formal merchant account. For supported personal/agent/payment-number routes, a structured TikiPay Direct workflow can reduce manual checking while the seller continues receiving money to the configured account. This can be useful for digital sellers, small ecommerce stores, SMM businesses, agencies and social sellers.

This does not change the legal or provider rules attached to the underlying account. The business remains responsible for using payment accounts in accordance with provider terms and applicable law. As the business grows, official merchant API onboarding may become the better long-term route.

12. Merchant API workflow

With an official merchant API, the application sends a create/payment request using protected merchant credentials, sends the customer through the supported checkout, receives provider/TikiPay status events and verifies the final state server-to-server. The process is designed for merchant-grade integration rather than an SMS bridge.

Store merchant credentials securely and follow provider-specific requirements for callback verification, refund or settlement reporting. TikiPay can act as the integration and automation layer, but provider-specific merchant obligations remain in force.

13. Website, WordPress and ecommerce integration

A custom website can call the TikiPay backend API from its server. WordPress/WooCommerce users can use a supported plugin when available. In both cases, the important sequence is the same: local order → create payment → customer payment → backend verify → local order update.

Do not put the Brand API key in page source. The browser should call your backend, and your backend should call TikiPay. This protects the credential and lets your server enforce amount and order rules consistently.

14. SMM panel, balance top-up and account credit

Balance top-up systems require strong duplicate protection because the paid action directly creates stored value inside another platform. Credit the balance only after a verified completed state and record the remote payment reference with the balance transaction.

If a callback is repeated, the balance operation must detect that the same payment has already been consumed. Pending or failed payments should never create temporary credit that can be spent before verification.

15. Telegram, Messenger, WhatsApp and chatbot automation

Bots can generate a payment link or hosted session, keep a conversation-specific order reference and wait for server verification. After completion the bot can unlock a command, file, subscription, membership or service.

Never trust a user-typed message saying paid. The bot should ask its backend for the current verified state. Workflow tools such as n8n can orchestrate these steps, but private credentials still belong in protected server/workflow secrets.

16. Digital products, courses and instant delivery

Payment automation is especially valuable when the customer expects immediate access. A digital file, course enrollment, private group link or software key can be delivered as soon as the payment becomes verified.

Protect the delivery asset itself. Do not place a permanent download or group link on a public success page. Use gated pages, short-lived tokens or account-based access so a copied URL does not bypass payment.

17. Pending payments and delayed synchronization

Pending is a normal operational state, not necessarily an error. Network delay, provider delay, an offline bridge device or a webhook retry can mean the payment signal takes longer to reach the server. The order should remain recoverable while the system waits or rechecks.

Give the customer a clear message and a reference number. Avoid creating a second order automatically unless the first session is known to be unusable. When connectivity returns, queued supported events can be synchronized and matched to existing pending orders.

18. Wrong amount and partial payment

Freeze the expected amount when the order is created. If the received/verified amount is different, do not auto-fulfil. Depending on business policy, keep the order in review, ask the customer to pay the difference through a new controlled session, or refund through the appropriate provider process.

Never silently change the local order total to match whatever payment arrived. That makes pricing rules vulnerable and complicates accounting.

19. Security and privacy

Use HTTPS, server-side credentials, role-based admin access and safe logs. For device-based SMS payment detection, process only the minimum data needed to identify supported payment events and send only the required normalized event data to the server. Follow your published privacy policy and platform permission rules.

Do not use the SMS bridge as a general message-reading feature. Restrict permission use and parsing to the supported payment automation purpose. Protect stored event data, define retention rules and provide users with transparent information about what the app reads and why.

20. Operational monitoring

Monitor completed, pending, failed and needs-review counts; median verification time; delayed-sync rate; duplicate attempts; API errors and webhook failures. These metrics tell you whether customers are paying successfully and whether the automation layer is keeping up.

Support staff should be able to search by local order ID and remote reference without seeing private API keys. Create a clear escalation path for provider outage, device bridge outage, credential problems and application fulfilment bugs.

21. Testing before production

Test more than the happy path. Run success, cancel, wrong amount, reused transaction, duplicate callback, customer closing the page, temporary internet loss, bridge reconnection, API timeout, webhook failure and fulfilment failure. Confirm that none of these conditions produce an unverified paid order.

For personal/agent workflows, test the exact Android device model and battery policy that will run in production. For official merchant API, test provider sandbox/live requirements separately.

22. Go-live and scaling

Start with controlled production traffic and watch verification latency and support messages. Keep a rollback plan for plugins/modules and a fallback support procedure for payments that remain pending longer than expected.

As volume grows, move fulfilment to queues, use database uniqueness constraints, centralize payment-state transitions and automate reconciliation reports. Scaling should make the same verification rules more reliable, not create shortcuts around them.

23. Practical workflow comparison

24. Production checklist — 30 checks

25. Extended FAQ

26. Final implementation notes

TikiPay Refer and Earn Program should be implemented as a verification-first workflow. The exact payment route can differ, but the safe architecture stays consistent: create a traceable local record, collect through an enabled provider route, synchronize or receive the payment signal, verify on the server, then perform the business action exactly once.

Use the TikiPay Developer Docs and the package-specific installation guide for endpoint names and current configuration values. Keep customer instructions simple, keep credentials private, and keep pending payments recoverable instead of forcing a manual paid decision.