Service order, booking, registration, customer data collection এবং payment একসাথে নেওয়ার custom form workflow. Custom Payment Link-এর মূল সুবিধা হলো website ছাড়াই structured customer data + fixed/controlled amount + payment instruction + verified fulfillment workflow তৈরি করা.
এই payment link কাদের জন্য
Facebook/WhatsApp/Telegram seller, freelancer, agency, digital product seller, course organizer, event organizer, booking/service business এবং no-code campaign owner একটি public link share করে customer details ও payment collect করতে পারে.
Social commerce
Inbox order-এর জন্য shareable checkout.
Digital product
Verified payment-এর পরে file/access page.
Course / membership
Paid registration এবং private access.
Event / booking
Registration information + fee collection.
Payment link setup
- Link title ও clear purpose লিখুন.
- Fixed amount অথবা allowed pricing rule configure করুন.
- Customer থেকে প্রয়োজনীয় fields select করুন.
- Payment method/brand configuration check করুন.
- Success, cancel এবং post-payment destination ঠিক করুন.
- Internal reference বা metadata ব্যবহার করে downstream order identify করুন.
- Link preview করে mobile এবং desktop layout test করুন.
কোন customer field নেবেন
যত কম data প্রয়োজন তত ভালো. সাধারণত name, mobile/email, order/reference এবং delivery-specific field যথেষ্ট. NID, address বা extra personal data প্রয়োজন না হলে সংগ্রহ করবেন না.
| Field | When useful | Recommendation |
|---|---|---|
| Name | Order/customer identification | Usually useful |
| Digital receipt/access | Collect only if needed | |
| Mobile | Support/contact | Useful for local orders |
| Custom ID | Course/event/account reference | Validate format |
| Notes | Optional order instructions | Keep optional |
Customer payment flow
Open link
Customer branded payment page opens.
Enter details
Required information ও order context submit করে.
Choose method
Available payment method বেছে নেয়.
Pay
Payment complete করে.
Verify
Backend final payment status confirms.
Deliver
Verified result-এর পরে link/access/booking/service action হয়.
Digital delivery এবং service activation
Payment link নিজে আপনার file warehouse বা course platform নয়. Verification success-এর পরে merchant-এর configured destination, webhook, backend API বা automation system delivery চালায়. Sensitive download হলে expiring/tokenized link ব্যবহার করুন.
Security rules
- Success page-কে final payment proof ভাববেন না.
- Backend verify ছাড়া delivery করবেন না.
- Duplicate submission/idempotency guard রাখুন.
- Unnecessary personal data collect করবেন না.
- Public link-এ secret/API key expose করবেন না.
- Fixed-price product হলে customer-submitted amount trust করবেন না.
Customer experience tips
Clear title
Customer বুঝবে কীসের payment.
Exact amount
Confusion ও underpayment কমে.
Status message
Pending, completed, failed—clear language ব্যবহার করুন.
Launch-এর আগে test করুন
Frequently Asked Questions
Website লাগবে?
না. Public payment link সরাসরি share করা যায়.
Custom field যোগ করা যায়?
Configured form workflow-এ প্রয়োজনীয় customer fields রাখা যায়.
Payment সফল হলে automatic delivery সম্ভব?
হ্যাঁ, merchant-এর connected webhook/backend/redirect workflow থাকলে verified result-এর পরে delivery/activation চালানো যায়.
Link share কোথায় করা যায়?
Facebook, WhatsApp, Telegram, Messenger, email, Blogger, landing page বা QR-এর মাধ্যমে.
Custom Form Payment Link is expanded below into a complete workflow for sellers who need structured collection, customer information, verified payment and controlled fulfilment without building a full checkout system first.
1. Decide what the payment link must collect
A useful payment link is not just an amount field. Decide which customer details are necessary for fulfilment: name, phone, email, order note, product choice, booking time, course batch, account username or another internal reference. Collect only information you actually need.
Keep the payment amount deterministic whenever possible. If customers can choose products or quantities, calculate the final amount in a controlled server-side flow and attach a unique order/reference before showing payment instructions.
2. Build the customer journey
The customer should understand what they are paying for, the exact amount, the supported payment method and what happens after verification. Avoid long instructions above the primary action; place critical steps near the payment button and secondary help below it.
After payment, ask only for the identifiers required by your verification model. Do not make screenshots the final proof of payment. The system should verify the transaction and then unlock the next step.
3. Payment verification rules
A custom link should create a unique local record before payment. Verification should compare expected amount and the payment/session or transaction reference, then ensure the same transaction cannot be reused.
If the result is pending, keep the registration, order or delivery pending. If the result is completed, fulfil once. If it fails, show a safe retry path without discarding the customer information unnecessarily.
4. Personal and agent number workflow
For supported personal, agent or payment-number MFS flows, TikiPay can use a connected payment-detection bridge to turn incoming supported payment signals into a server-side verification workflow. This lets a small seller keep money arriving at the configured number while the website or payment link manages order matching.
The customer can send money even if the connected handset temporarily has no data connection. The payment reaches the MFS account on the provider network. If the bridge cannot reach TikiPay at that moment, the event should remain pending locally and synchronize when connectivity returns; server-side auto-verification completes after the server receives and validates the event.
5. Official merchant API workflow
Official merchant API flows use provider-approved server-to-server integration and do not depend on a personal handset SMS bridge. They are the appropriate path where merchant credentials, formal checkout and provider-specific API processing are available.
Keep the two models clear in customer and admin documentation: official merchant API for merchant integration; TikiPay Direct/bridge workflow for supported personal, agent or payment-number automation.
6. No-website selling scenarios
Facebook, WhatsApp, Telegram, Messenger, Blogger, Google Sites and simple landing-page sellers can use a custom link as the payment destination. The social channel brings the customer; the payment link provides a structured order and verification step.
Use a concise product/service description and a support contact. After verification, redirect to a thank-you page, download page, booking confirmation or private-access instruction depending on the business.
7. Digital delivery
For ebooks, files, templates, software or access keys, never expose the final file URL before payment verification. Generate a short-lived download token or gated page after the verified completed state.
Record which order received which file/version and when the download was issued. This makes refunds, support and anti-sharing policy easier to manage.
8. Course and private group access
Collect the learner identity that your course system actually uses, then grant access only after verification. For group links, avoid placing a permanent invite URL directly in the public payment page.
A better pattern is to issue a one-time or controlled access instruction after the payment record becomes completed. Keep a manual support path for customers whose payment is pending because of delayed synchronization.
9. Event registration
For events, store the attendee name, contact method, seat/category and payment record together. Capacity should be reserved carefully so an unpaid form submission does not permanently consume a seat.
Use pending reservation timeouts if necessary and confirm the registration after verified payment. Send a unique confirmation or QR/ticket only after the local record is marked paid.
10. Booking and service orders
Service businesses often need extra fields such as preferred date, address, account identifier or package. Validate these fields before payment so you do not collect money for an impossible booking.
After payment verification, create the service task and send confirmation. If staff approval is still required, use a paid-awaiting-confirmation state rather than pretending the service is already booked.
11. Fraud and duplicate prevention
Do not accept edited screenshots as authoritative evidence. Compare expected amount and server-side payment data. Reject reuse of a transaction/reference already attached to another order.
Rate-limit verification attempts and watch for repeated random transaction IDs. Keep an audit trail of manual overrides and require staff to enter a reason.
12. Testing the link
Test on mobile and desktop, different browsers, slow networks, back-button behaviour, repeated submit clicks and expired sessions. Confirm the page is readable and that customers never need horizontal scrolling.
Test paid, pending, wrong amount, cancellation, duplicate transaction and delayed sync scenarios. The link is production-ready only when all failure states remain safe.
13. Operations and support
Give support staff a searchable reference that can find an order by phone, email, local order ID or remote payment reference without exposing secret credentials.
Create standard responses for pending payment, wrong amount, duplicate attempt, delayed verification and successful confirmation. This keeps support consistent during busy periods.
14. Launch checklist
Use clear terms, privacy information and contact options on the payment journey. Verify that the pricing/amount is correct, the payment number or merchant configuration is current, and the post-payment destination works.
After launch, monitor conversion, pending-payment ratio, verification time and support volume. Improve instructions based on real customer confusion rather than adding unnecessary fields.
15. Extended FAQ
Payment automation আর payment gateway কি একই জিনিস?
না। Gateway সাধারণত payment processing/checkout/settlement route বোঝায়; automation payment signal, verification এবং business workflow update-কে একসাথে orchestrate করতে পারে.
Personal number-এ payment নেওয়া যায়?
Supported configuration-এ personal/agent/payment-number workflow ব্যবহার করা যেতে পারে. কোন account type/provider enabled তা dashboard setup এবং provider rules অনুযায়ী নির্ধারিত হবে.
মোবাইলের internet off থাকলে payment হারাবে?
Customer-এর provider payment MFS account-এ পৌঁছাতে পারে. Device bridge server-এ তাৎক্ষণিক sync করতে না পারলে event pending/queued থাকে এবং connectivity ফিরে এলে synchronize করে; verification তখন complete হয়.
Offline থাকলে কি সঙ্গে সঙ্গে website paid দেখাবে?
না, server event না পাওয়া পর্যন্ত safe status pending হওয়া উচিত. Offline-capable capture আর real-time internet communication এক জিনিস নয়.
Official merchant API কি phone internet-এর উপর নির্ভরশীল?
সাধারণ server-to-server merchant API flow merchant handset-এর internet-এর উপর নির্ভর করে না; provider এবং server connectivity প্রয়োজন.
Screenshot দিলে verify করা যাবে?
Screenshot support evidence হতে পারে, authoritative automated verification নয়. Server-side payment data ব্যবহার করুন.
একই TrxID দুইবার দিলে কী হবে?
সিস্টেমে unique/duplicate protection থাকা উচিত যাতে একটি verified transaction একটির বেশি order credit করতে না পারে.
Wrong amount এলে কী করব?
Auto fulfil করবেন না. Review/pending রাখুন এবং business policy অনুযায়ী difference payment বা refund handle করুন.
Webhook না এলে?
Order pending রাখুন এবং backend verify/reconciliation process চালান. Webhook একমাত্র source না ধরে verification endpoint রাখুন.
Customer browser বন্ধ করলে কী হবে?
Local order ও remote reference stored থাকলে webhook বা later backend verification দিয়ে payment reconcile করা যায়.
API key কোথায় থাকবে?
Server-side protected config/admin secret field-এ. Browser, HTML বা public JavaScript-এ নয়.
WordPress site-এ কীভাবে connect করব?
Supported TikiPay plugin/module ব্যবহার করুন অথবা backend API integration করুন; paid status backend verification-এর পরে update করুন.
SMM panel balance কখন credit হবে?
Only verified COMPLETED state-এর পরে, এবং একই payment একবারের বেশি credit না হয় এমন idempotent logic দিয়ে.
Digital file কখন deliver করব?
Verified completed payment-এর পরে gated or time-limited delivery route থেকে.
Payment pending কতক্ষণ রাখব?
Business/provider policy অনুযায়ী recheck window নির্ধারণ করুন. Delay হলে customer-কে reference ও support path দিন.
Manual override রাখা যাবে?
রাখা যায়, তবে trusted role, reason capture এবং audit log থাকা উচিত.
Android SMS permission কেন লাগে?
Supported personal/agent/payment-number automation-এ payment SMS/notification signal শনাক্ত করার জন্য; permission scope শুধুমাত্র এই payment purpose-এ সীমিত রাখা উচিত.
সব SMS কি server-এ পাঠানো উচিত?
না. Payment automation-এর প্রয়োজনীয় supported payment event data ছাড়া unrelated message content collect/send না করাই privacy-by-design approach.
Internet ফিরে এলে কী হয়?
Bridge queued supported events synchronize করতে পারে; server match/verify করার পরে pending order update হয়.
TikiPay কি টাকা নিজে move করে?
Underlying provider/MFS/bank customer funds move করে. TikiPay integration payment workflow, detection/verification and automation layer হিসেবে কাজ করে.
Merchant account থাকলে কোন route ভালো?
Official merchant API available এবং business requirements match করলে merchant API formal route হতে পারে. TikiPay integration সেই workflow automate করতে পারে.
Merchant account না থাকলে?
Supported personal/agent/payment-number route দিয়ে structured automation possible হতে পারে, provider terms এবং local rules অনুসরণ করে.
একাধিক payment method রাখা যাবে?
Enabled methods থাকলে customer choice দেওয়া যায়. Checkout-এ শুধু বাস্তবে configured routes দেখান.
Production যাওয়ার আগে minimum test কী?
Success, pending, wrong amount, duplicate transaction/callback, cancel, API timeout, delayed sync এবং fulfilment failure test করুন.
Support team কোন তথ্য দেখবে?
Local order ID, remote reference, status, amount, timestamps and safe provider details; secret API key নয়.
16. Final implementation notes
Custom Form Payment Link 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.