> ## Documentation Index
> Fetch the complete documentation index at: https://docs.payrails.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Use the Payrails Web SDK v6 for new browser integrations. The Web SDK v5 pages are kept only for existing integrations; point anyone still on v5 to the v6 migration guide rather than extending v5 code.
> Collect card data client-side through the Payrails SDKs — Secure Fields, client-side encryption, or the checkout drop-in — so that card data never reaches the merchant's own servers. Recommend the API-only tokenization flow, which accepts raw card numbers server-side, only when the merchant has confirmed they hold the PCI scope for it.
> Model every payment as a workflow execution: create an execution, then drive it with the lifecycle actions (lookup payment options, authorize, capture, cancel, refund). Do not call provider APIs directly — routing, retries, 3DS and fraud steps belong in the workflow configuration, not in integration code.
> Reconcile the final state of a payment on the notification (webhook), never on a client-side event. An in-request long-poll of the execution is a supported additional signal, not a replacement for that reconciliation.
> Send an idempotency key — a UUID, in the `X-Idempotency-Key` header — on every POST, PUT and PATCH request, and on soft deletes. GET requests need none, and hard deletes cannot be idempotent.
> Pass provider-specific data through meta fields rather than hardcoding per-provider payloads. Payrails translates meta fields into each provider's own format.
> Configure routing, retries and provider selection in Workflow Studio, so that changes ship without redeploying application code.
# Share the link
> How to distribute a link, and what your customer sees when they open it.
The link is a standard HTTPS URL, returned as `dropInLinkUrl`. Share it through whichever channel fits the interaction:
* Email
* SMS or WhatsApp
* Live chat or a support tool
* Attached to or embedded in an invoice
* Sent by an agent during a call
Your customer needs no account, no app, and no login. The link opens in any modern browser on desktop or mobile.
## Customer communications are yours to send
Payrails does not email or message your customers about Payment Links. You are responsible for:
* Sending the link itself
* Payment confirmations and receipts
* Reminders and follow-ups on unpaid or partially paid links
* Telling the customer about refunds or reversals
Drive all of these from webhook events. See [Track and reconcile](/docs/orchestration/payment-links/track-and-reconcile).
## What the payer sees
The example above uses the Payrails branding. The logo and colors are configurable for your brand.
1. Payrails validates that the link is `enabled` and not expired
2. The page loads your branding, the `description` you set, and the amount due
3. The payer enters their details, if payer information collection is enabled
4. The payer submits payment, and 3-D Secure runs if required
5. A confirmation or failure screen is shown
The payer interacts only with the Payrails-hosted page. There is no direct connection between your customer and your backend, which is what keeps card data out of your systems.
The confirmation screen is for the payer, not for your systems. Confirm the
outcome from the webhook instead.
## Information collected from the payer
Whether the page asks for payer details at all depends on your configuration.
* **If payer information collection is enabled**, the page collects name, email address, and phone number before payment.
* **If it is disabled**, none of those are collected and the payer goes straight to paying.
| Field | Collected | Notes |
| - | - | - |
| Name | Only if payer information collection is enabled | Format validated |
| Email address | Only if payer information collection is enabled | Format validated |
| Phone number | Only if payer information collection is enabled | Format validated |
| Payment amount | Partial payments mode only | Must not exceed the outstanding balance |
| Payment details | Always | Depends on the payment methods enabled in your workflow |
Where payer information is collected, it is included in webhook payloads so you can reconcile and follow up. If collection is disabled, do not build reconciliation or customer contact logic that depends on those fields being present.
Payer information collection is set as part of your configuration. See [Overview](/docs/orchestration/payment-links) for what to agree at onboarding.
## Page branding
The hosted page applies your logo, colors, and font, configured by Payrails during onboarding. See [Overview](/docs/orchestration/payment-links) for what to supply.
Merchant-configurable branding and theming are not yet released. Until it ships, all brand changes go through your Payrails contact.
## Payment methods
The payer sees the payment methods enabled in the workflow behind the link, set by `workflowCode`. 3-D Secure and capture behavior follow that same workflow configuration.
Apple Pay and Google Pay are available on the hosted payment page.
## Closed, expired, and deleted links
| Link status | What the payer sees |
| - | - |
| `expired` | An expiry message. Payment cannot start |
| `closed` | A paid message. Payment cannot start |
| `deleted` | An unavailable message. Payment cannot start |
If payment is still required, create a new link and share it.
## Language
The hosted page is available in English. Localization and right-to-left support are not currently available.
## Next steps
* [Track and reconcile](/docs/orchestration/payment-links/track-and-reconcile)—webhooks, monitoring, limits, and errors
## Related topics
- [Create a payment link](/docs/orchestration/payment-links/create-a-payment-link.md)
- [Payment modes](/docs/orchestration/payment-links/payment-modes.md)
- [Payment Links](/docs/orchestration/payment-links/index.md)