Create a payment link that stays connected to the order

Start with an identifiable payment request

Create a request record before generating the link. Give it an internal reference, the agreed amount, currency, customer-facing description and a responsible team member. Keep the quotation or order reference separately from any provider transaction identifier. One order can produce several attempts, so a single field called payment ID usually becomes insufficient. For example, a design agency might request a deposit against project A104 and collect the balance later. Those are two requests with different amounts, even though they belong to the same commercial engagement.

Payment links

Check the destination and the amount

Before sharing, open the payment page in a clean browser and review the amount, currency and business identity. Check the destination host against the approved checkout domain. A shortened URL may save space but makes the destination harder for a customer to inspect. If the commercial amount changes, follow the platform's supported update or replacement process and retire obsolete requests. Do not assume a message saying that an old link is cancelled actually disables it. Record which request remains valid and how staff can find that record.

Payment webhooks

Separate link delivery from payment completion

Sending a link, opening it and completing a payment are different events. A customer may open the page on a phone, abandon authentication and return from a laptop. Staff should therefore avoid marking an order paid from a chat acknowledgement or a screenshot alone. Use verified transaction status to update the order. Stripe and Mollie document their own payment-link products; their features and account requirements must be assessed independently. A generic link workflow does not mean that every provider offers identical expiry, customisation or notification behaviour.

Handle duplicate and unfinished attempts

Agree what happens when a customer clicks twice or requests a replacement link. Your records should distinguish the intended request from the attempts associated with it. An unresolved attempt should enter a review queue rather than immediately producing another charge. In the agency example, an employee checking the deposit should inspect the existing payment status before sending a second request. If two payments genuinely succeed, handle the overpayment through a documented adjustment or eligible refund process. Do not quietly discard the second transaction from reporting.

• Keep the order reference stable across attempts.
• Record the provider transaction identifiers separately.
• Assign a person to unresolved requests.
• Preserve the reason when replacing a request.

Make follow-up useful and proportionate

A useful reminder identifies the order, amount and next step without exposing unnecessary personal information. Establish who may send reminders and when an unresolved request becomes a support case. A customer who already paid should have a straightforward way to provide a reference so staff can investigate. Do not put private details into link query strings or public descriptions merely to make reconciliation convenient. Use an internal record for sensitive context, and keep the public payment page limited to information the customer needs to recognise the request.

Place OrsunPay in the workflow

OrsunPay can connect payment links to supported provider accounts and verified payment events. The merchant keeps its own PSP agreement, and the PSP processes and settles funds; OrsunPay software fees are separate. Payment-link management in the cabinet is currently live-mode functionality. A link is neither a receipt nor proof that funds settled. Before launch, confirm the supported account, payment methods and deployment configuration, then test a successful payment, an abandoned checkout and a repeated attempt. The deliverable is a traceable order workflow, not just a working button.

Sources

• Stripe — Payment Links
• Mollie — Payment links