A customer pays for a workshop place and sees a success page. Your team still needs to know which booking was paid, whether the amount is correct and whether admission has already been granted.
Receiving USDC answers where the money went. Completing an online order requires connecting that payment to a business record. A return URL and a payment callback help with different parts of that job.
AI-generated concept illustration. The screens and notification symbols are explanatory, not a product screenshot or a verified integration.
Give the customer a useful next page
A redirect brings the customer's browser back to a destination you configure. That page can explain what happens next: where to find a booking reference, how to contact support or how to check an order.
The current PayIn payment view supports a configured return URL after its successful-payment state. That is useful navigation, but a visit to your success page is not independent payment evidence. Someone can open a page directly, and a paying customer can close the tab before returning.
Design the return page around an order reference and a server-verified status. For an uncertain result, show that you are checking and provide a support path rather than immediately asking the buyer to pay again.
Send the business a separate notification
A callback, often called a webhook, is a server request to your configured endpoint. The current PayIn source has a payment.completed notification path when settlement reports success with a transaction hash. Creation accepts a callback URL and signing secret.
That path can supply payment identifiers, the amount, currency, network and transaction information to an integration. It does not automatically update your shop, issue tickets or send a parcel. Your system must implement those actions.
The code supports an HMAC-SHA256 signature with a configured secret. A production integration must verify the deployed event contract and signature behavior; this article is not a claim of guaranteed delivery or durable retries. Use the current notification documentation, rather than the separate historical PayIn Open contract.
| Mechanism | Who receives it | Useful for | Merchant responsibility |
|---|---|---|---|
| Redirect | Customer browser | Returning to an order or next-step page | Read verified order status from your server |
| Completion callback | Merchant endpoint | Triggering payment checks and order processing | Verify, match and process safely |
| Payment history | Authorized merchant operator | Reviewing receipts and investigating gaps | Reconcile payments with business records |
Establish the order relationship before automating delivery
Suppose two customers buy the same workshop place for the same amount. The total alone cannot tell you whose booking to confirm. A standard reusable link does not automatically attach each receipt to your booking system.
An integration needs a deliberate relationship between its order record and the payment identifier. Confirm the supported creation and status flow before implementing it. Do not invent order fields or assume an arbitrary reference in a browser URL will appear in a callback.
Before fulfillment, verify the expected receiving setup, amount, currency, network and completed payment status. Keep the transaction and payment reference with the order for later investigation.
Make one paid order produce one fulfillment action
A receiver may encounter a repeated notification or an operator may run reconciliation again. Store a persistent record that the relevant order has already been fulfilled, so processing the same payment cannot issue a second ticket or dispatch another parcel.
This is an integration requirement, not a built-in PayIn ticketing feature. Test the receiver with synthetic examples: valid and invalid signatures, duplicates, missing order matches, delayed events and temporary outages. Keep secrets and real customer data out of public examples.
Plan for a customer who paid but did not return
The order should remain recoverable even if the buyer closes their browser. Give support a way to look up the order and payment reference, inspect the persisted record and reconcile it.
Likewise, an endpoint outage should lead to investigation and reconciliation, not an assumption that payment never happened. Keep a manual review route until your own integration has been tested end to end. Never treat a callback configuration field as a delivery SLA.
Choose the right first step for your business
A seller handling a small number of custom orders can begin with a payment link and manual matching. A business that needs immediate access or automated fulfillment should plan and validate an order-aware integration.
Review PayIn integration capabilities and the current payment-link documentation. For the matching problem itself, read how to distinguish equal-amount payments.