A payment button in a Telegram bot is easy to forward. If another person opens the link or presses “Check payment”, your bot must still know who owns the purchase. This guide describes an integration you build in your own bot backend; it does not imply that Trust Gateway supplies a ready-made Telegram plugin.
Start with trusted buyer identity
Identify the buyer from an incoming event authenticated according to your Telegram integration. Use a stable platform user identifier as the account mapping. A display name or username can change and should not be your ownership key. When a purchase starts in a group, distinguish the person buying from the conversation where the message appeared.
Look up the selected product in your catalogue and calculate its price on the server. Do not let callback text or a message containing an amount override the catalogue. Save a product snapshot so later price edits do not silently change the purchase already offered to this customer.
Keep three references separate
A local record needs a buyer ID, local purchase ID and gateway order ID. The first determines who receives the benefit, the second identifies what was purchased, and the third identifies the payment to verify. Retain the returned exact payable amount and expiry with those references.
local_purchase_id: internal purchase reference
buyer_platform_id: authenticated bot user identifier
product_snapshot: item and agreed price
gateway_order_id: returned Trust Gateway reference
payable_amount_paise: exact checkout amount
state: pending, paid, fulfilled or reviewThese are suggested fields in your own database, not additional parameters supported by the gateway create endpoint. Use the API reference for request fields.
Send a checkout URL without secrets
Your backend creates the gateway order using its private API key and sends the returned hosted checkout URL to the buyer. Never include the API key, bot token or receiving-account credentials in a message. A “Check payment” button can carry an opaque local purchase reference for your server to resolve.
Before returning purchase details, check that the person pressing the button owns that purchase. Forwarding a message must not transfer a membership or licence to its new viewer. If your service supports gifts, store the intended beneficiary explicitly at creation instead of inferring it from the last person to click.
Fulfil for the stored buyer once
Query the authenticated status endpoint with the saved gateway reference. Require the verified paid state, matching order ID and exact payable amount. Update the purchase atomically and create a single delivery task addressed to the stored buyer. Repeated buttons and callbacks should find that same task rather than grant another benefit.
For private digital goods, deliver to the intended private conversation. If messaging fails, retain a delivery-pending task and retry that operation. Payment can be confirmed while delivery remains incomplete; asking the buyer to pay again would not solve the messaging problem.
Handle uncertain payments honestly
Show a support reference and pending status while verification is incomplete. A screenshot or payer name does not uniquely identify a payment when several people buy the same product. Staff should investigate through the stored order mapping and authenticated result. Use bounded background checks so rapid button presses do not create unlimited API traffic.
Test two equal-price purchases, a forwarded message, repeated checks and a failed delivery message before launch. Combine this design with status polling without webhooks and the licence fulfilment guide.