Use Payment Links

A Payment Link is a reusable hosted checkout URL. Create an offer in the dashboard and share the same link on your site, in messages or campaigns, or as a QR code.

Creating, editing, or previewing a link does not charge a customer. The checkout starts a separate purchase attempt when the buyer begins the interactive flow.

Prerequisites

• Products and Prices exist for every item in the offer.
• The Payment Link is ACTIVE and has not passed expiresAt.
• At least one valid payment route supports the intended country and currency.
• Branding, custom fields, promotion codes, installments, and checkout settings are configured as needed.
• For an API integration, a webhook endpoint is ready to verify the payment result.

Configure and publish

1. Create or select the Products and Prices you want to sell.
2. Open Collections → Payment Links, select Create Payment Link, or use the Payment Links API.
3. Configure the offer, custom fields, promotion codes, allowed installments, branding, expiration, and what happens after checkout.
4. Activate the link and copy its hosted /checkout/:slug URL.
5. Complete a Sandbox purchase and check the invoice and payment result. If you integrate with the API, also verify your webhook handler.
6. After testing, configure the Production offer and share its URL on your site, in a campaign or message, or as a QR code.

<a href="https://checkout.example.com/checkout/summer-offer">
  Buy now
</a>

The URL is the capability that opens the offer. Keep campaign parameters on the published URL when you need attribution. A custom domain changes the public host, not the Payment Link identity or its downstream lifecycle.

Coupons and automatic promotions

In the editor's promotions section, select the automatic promotions for this offer and enable Allow coupons when buyers should enter a code. Creating a coupon or promotion alone does not configure the link. Review Coupons, Promotions and Combine discounts.

Save the offer and use a new Sandbox attempt to verify eligible and ineligible benefits. Preview shows configured benefits, while the final quote confirms applicability. An existing Checkout Session keeps its snapshot.

Integration details

The following sections explain Checkout Sessions, confirmation settings, and the events your backend must verify. For a dashboard-only workflow, check the resulting invoice.

Runtime flow

1. The buyer opens the shared URL and Pharos resolves the active Payment Link.
2. Starting the interactive checkout creates a Checkout Session snapshot or resumes the matching open session for that browser tab.
3. The session preserves the offer's items, prices, recurrence, fields, promotions, installments, and expiration for this attempt.
4. The buyer enters contact and billing details, selects an available payment method, and submits the purchase.
5. Pharos validates the offer, calculates the final amount, and creates the applicable customer, invoice, subscription, payment, and payment-attempt records.
6. The payment may complete immediately, require another action, or continue processing. Checkout shows the result or the next instructions.
7. Your backend verifies and deduplicates the signed invoice.paid event before fulfilling a paid purchase.

Reusable template and session snapshot

The Payment Link and its Checkout Sessions have independent lifecycles:

• Editing products, prices, fields, promotion settings, or installments affects only sessions created later.
• Setting the link to INACTIVE, expiring it, or deleting it prevents new sessions.
• An already-open session keeps the snapshot created for that buyer attempt until the session completes or expires.
• Refreshing the same flow can resume its matching open session; the public URL remains /checkout/:slug.
• Dashboard preview remains presentation-only and creates no Checkout Session, invoice, subscription, or payment.
• The confirmation message or redirect destination is copied into the Checkout Session snapshot. Editing the Payment Link later does not change sessions already opened.

Configure what happens after checkout

Choose CONFIRMATION to show Pharos's order summary with the default message or a plain-text custom message. Custom messages are displayed exactly as written and are not translated based on the buyer's location.

Choose REDIRECT to navigate the buyer to an HTTP(S) destination after a non-failed completion, including processing and no-payment-required outcomes. The URL may contain {CHECKOUT_SESSION_ID}, which Pharos replaces before navigating. Localhost destinations are available only in Sandbox.

Redirecting the browser does not prove that payment succeeded. In particular, a processing payment may redirect before its final provider result; fulfill only from the signed authoritative webhook.

Understand the outcome

Checkout Session status and paymentStatus answer different questions:

A browser success page or checkout_session.completed webhook is not proof that funds were collected. Asynchronous payment methods may finish after the buyer has left checkout.

Troubleshooting

• The link is not found: Confirm the slug, active status, deletion state, and expiration.
• The offer has no valid price: Confirm every linked product has a Price and that the cart has a valid composition.
• A country, currency, or method is missing: Confirm the full cart supports it and that an enabled payment connection and route are available.
• Recent edits are not visible: Start a new attempt. An existing session intentionally keeps its original snapshot.
• A buyer appears stuck: Retrieve the related session and compare its status, paymentStatus, and expiration before asking the buyer to retry.
• Your system did not fulfill: Check signature verification, duplicate handling, delivery attempts, and whether invoice.paid was received.

Next steps

• Compare with Cart Checkout
• Implement Collections Webhooks
• Review Checkout Concepts