Sales teams like payment links because they can be pasted into a chat window. Compliance teams like them for a different reason, and that reason is worth more money: a hosted page keeps the card number inside the provider's environment, which pulls most of the PCI DSS obligations off your infrastructure and onto theirs.
What happens when the link is opened
You call the provider's API with an amount, a currency, a reference and usually a customer identifier. The provider returns a URL. When the customer opens it, they land on a page hosted by the provider, on the provider's domain or a subdomain you have delegated, where they enter the card details. The provider runs 3D Secure if the issuer asks for it, authorises the payment, and then does two things: it redirects the customer to a return URL you specified, and it sends a webhook to your server describing the outcome.
The redirect is for the human. The webhook is the record. Any system that treats the redirect as confirmation will eventually book a payment that never settled, because a customer who closes the tab after paying never reaches your return URL. That failure mode is the same one covered in webhook automation safety, and it is the single most common integration bug we see.
Where the liability sits
On a hosted page the provider is the one presenting the card form, so the provider carries the PCI scope for capture. You still have obligations, but they shrink from the full self assessment questionnaire down to a much smaller set, and the difference in audit effort is significant for a small firm.
Strong customer authentication follows the same pattern. The hosted page runs the 3DS 2 flow with the issuer, which shifts fraud liability on authenticated transactions in the way explained in the 3DS 2 guide. What does not shift is chargeback risk on disputes that are not fraud, such as a client claiming the service was not delivered. Those still land on you, and the defence file still has to come from your records, as set out in how chargebacks work.
A payment link is a payment instrument, not a contract. If the client agreed to terms on a page you control, keep the record of that acceptance with the transaction reference, because a hosted checkout will not capture it for you.
Single use versus reusable
Providers offer two shapes and they behave very differently in reconciliation. A single use link is bound to one amount and one intended payer, expires, and maps cleanly to one expected payment. A reusable link is a permanent URL that anyone can pay, sometimes with an amount the payer enters. It is convenient for a support desk and a menace in accounting, because you cannot tell in advance who is going to pay or how much.
For a broker or prop firm handling client deposits, single use links with a short expiry and a reference tied to the client account are the only sane default. The reference is what lets an automated system credit the correct account without a human reading a bank statement. Firms that skip that field end up staffing a reconciliation desk to solve a problem that a string field would have prevented.
The specific traps
Currency is the first. The link is created in one currency and the card may be issued in another, so the customer is offered a conversion at the checkout or the issuer converts at settlement. Either way the amount that reaches your account is not the amount on the link, and if your system credits the client with the link amount you take the FX difference every time. The mechanics are in FX conversion at the payment provider.
Second is expiry and replay. A link with no expiry is a live payment page indefinitely, and one that has been forwarded to a group chat will get paid by the wrong person. Set an expiry measured in hours for deposits.
Third is approval rate. A hosted page is a redirect away from your brand, and unfamiliar checkout pages get abandoned and get declined more often when the issuer sees a mismatch between the merchant descriptor and where the customer thinks they are. Matching the descriptor to the brand the client actually knows is basic hygiene, and the wider set of causes sits in why payments get declined.
When links are the wrong tool
Recurring billing is the clear case. A link authorises one payment, so building a subscription out of a monthly reminder and a fresh link is a churn machine compared to a stored credential and a scheduled charge, which is the argument in recurring billing. High volume deposit flows are the other case: once you are processing hundreds of deposits a day, an embedded checkout inside your client portal converts better than a redirect, and the routing logic across multiple providers has to live in your own layer anyway. That is the design behind the deposit flow in the Broker CRM, and the reasoning is in running multiple payment providers.
"Treat the webhook as the truth and the redirect as a courtesy. Every firm that books payments off the redirect eventually credits an account that was never paid for."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- A hosted payment link keeps card data inside the provider's environment, which cuts your PCI scope and runs 3DS on the provider's page.
- Book the payment from the webhook, never from the browser redirect, because customers close the tab before returning to your site.
- Use single use links with a short expiry and a client reference, so deposits reconcile automatically instead of by hand.
- Links authorise one payment, so subscriptions and high volume deposit flows need stored credentials or an embedded checkout instead.
Frequently Asked Questions
Do I need a website to accept payment links?
No. The checkout page is hosted by the payment provider, so the link can be sent by email, chat or invoice and paid without any site of your own. You do need somewhere to receive the webhook that confirms the payment, which can be a small server endpoint rather than a full website.
Are payment links safe for the customer?
The card details are entered on the provider's own page and are subject to the same 3D Secure authentication as any other card payment. The risk sits elsewhere: a link forwarded on to someone else still works until it expires, so short expiry times and single use links matter.
Can payment links be used for recurring subscriptions?
A link authorises a single payment. Some providers can create a stored payment method during that first checkout and charge it on a schedule afterwards, but sending a new link every month is a poor substitute for a proper subscription setup and produces avoidable churn.
About the Author
Roman Onta is an Executive Director at SINGUARD. He builds the Prop Firm CRM, the Broker CRM, Scalegram and CopySignals side by side with his brother Alex Onta, and he helped on the design of eTrader, the division Alex built and leads. His ground is worldwide payment processing, AML compliance and the corporate structures brokers are built on, work the two of them carry together, shaped by executive roles in the UAE and international corporates. He lives and works in Dubai for most of the year. Meet the executive duo leading Singuard's five divisions.