> ## 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.
# Payment Links
> Collect payments outside your checkout with a secure, Payrails-hosted payment page.
## What Payment Links are
A Payment Link is a shareable URL that opens a Payrails-hosted payment page. You create the link from your backend or from the Payrails Portal, share it with your customer through any channel, and Payrails handles the payment page, the processing, and PCI compliance.
No frontend integration is required, and your customer does not need an account or an app. The link opens in any browser.
In the Payrails API reference, this resource is called a drop-in link, and the
endpoints live under `/merchant/dropInLinks`.
## When to use Payment Links
Use Payment Links when payment happens outside your main checkout flow:
* An agent or support team member collects payment during a call or a chat
* You request payment after an order, a booking, or a service interaction
* You collect a deposit, an installment, or the balance of an invoice
* Several people need to contribute towards one total
* You want to start accepting payments without building a checkout integration first
Use Payrails SDK solutions instead when payment is embedded directly in your product's purchase flow.
## Payment Links compared with Payrails SDK solutions
| Aspect | Payment Links | Payrails SDKs |
| - | - | - |
| Where payment happens | Payrails-hosted page, opened from a link | Embedded in your own checkout flow |
| Integration effort | One API call, or no code via the Portal | SDK integration |
| Who initiates | You or your agent, asynchronously | The customer, in session |
| Frontend work | None | Required |
| Partial payments | Supported | Not applicable |
| Best for | Assisted, operational, and follow-up payments | Your primary purchase flow |
## What you get
| Property | Details |
| - | - |
| Payment page | Hosted by Payrails |
| Creation | API or Portal |
| Payment modes | Single payment, or partial payments against a total |
| Payment methods | All payment methods you have enabled in your workflow |
| Branding | Configured by Payrails during onboarding |
| Language | English |
| Domain | Payrails-managed |
| Notifications | Webhooks |
| Expiry | Required on every link |
| Editing a link | Not supported. As a workaround, you can delete a link and create a new one |
***
## Before you start
Payment Links is enabled and configured per merchant account rather than self-serve. Agree on the following with your Payrails contact before going live.
| Setting | What to provide | Why it matters |
| - | - | - |
| Brand assets | Logo, brand colors, font | Applied to your hosted payment page |
| Required payer fields | Which fields the payer must complete | Controls what the hosted page collects |
| Capture behavior | Immediate or delayed capture | Set through your workflow configuration |
### What to prepare on your side
* API credentials for the test environment
* The workflow code used for payment acceptance
* An HTTPS webhook endpoint that accepts POST requests and acknowledges quickly
* A merchant reference scheme you can reconcile against, such as an invoice or order number
### Test and live environments
Test and live environments are isolated:
* Webhooks are configured separately for each environment
* A link created in test cannot be used in production
* Validate the full lifecycle in test, including a webhook you have actually received and processed, before enabling live
Repeat your configuration in the live environment before launch. Environment mismatch is one of the most common causes of a failed go-live.
## Next steps
* [How it works](/docs/orchestration/payment-links/how-it-works)—the lifecycle, link statuses, and who is responsible for what
* [Create a payment link](/docs/orchestration/payment-links/create-a-payment-link)—your first link in test
## Related topics
- [Share the link](/docs/orchestration/payment-links/share-the-link.md)
- [Create a payment link](/docs/orchestration/payment-links/create-a-payment-link.md)
- [List drop-in links](/reference/listdropinlinks.md)