Run payment links like a sales channel.
Set a fixed amount, customer-entered payment, or a line-item mini cart in one link. Every channel shares the same payment context, controls, and operational memory.
Amount due
TRY 12,500
3 amount models
Fixed amount, customer entry, and line-item cart on one link surface.
4 states
Active, inactive, archived, and expired links keep the ops lifecycle clear.
2 completion screens
Hosted confirmation, custom message, or redirect after payment.
A link is packaged payment behavior, not an empty URL.
Amount, customer data, post-payment routing, and sales context live on one surface. The link carries the same checkout experience regardless of channel.
Fixed collection
Single-price services, deposits, or quick sales keep a clear link amount.
Customer amount
Donations, top-ups, or open invoices stay within min and max bounds.
Line-item cart
Product, description, quantity, and unit price travel together in the link.
Custom fields
Order notes, reference numbers, or department info at checkout.
Contact and address
Phone, billing, and shipping fields when your sale needs them.
Post-payment flow
Stay on hosted confirmation, show a custom message, or redirect.
Pricing shape follows the sales scenario.
Payment Links does not force fixed and open amounts into one mold. The link behaves the way you sell.
Clear amount
Single currency
Fast sharing
The dark section shows running flows, not a single poster.
The link must be active, unexpired, and structurally valid to accept payment. This block explains that runtime in product language.
Publish
An active link goes to channels and routes to the same checkout.
Validate
Amount mode, address needs, and post-payment behavior are evaluated together.
Collect
The customer enters checkout; the link keeps sales context.
Complete
Hosted confirmation, custom message, or redirect finishes the journey.
The link decides what the checkout collects.
Not every link opens the same form. Address, phone, custom fields, and internal reference ride with the payment context.
Payment context follows the link wherever it goes.
Sales, support, or a physical touchpoint can share the same payment destination.
Link lifecycle reads as a line, not a card stack.
Active, inactive, reactivated, and archived states follow how sales ops actually moves.
Publish
The link is ready to accept payment and go to channels.
Pause
Pause temporarily when campaign, stock, or ops changes.
Reopen
Reactivating keeps the same sales context.
Archive
Closed campaigns or old quotes become terminal.
Enterprise quote
ACTIVEpay.hsrcpay.com/l/b2b-offer
TRY 24,000
Service deposit
INACTIVEpay.hsrcpay.com/l/deposit
TRY 1,500
Past campaign
ARCHIVEDpay.hsrcpay.com/l/spring
TRY 799
List, update, and archive are part of product ops.
Payment Links is not only link generation. Sales watches active links, reopens paused ones, and archives closed campaigns.
Customers are not left in a void after payment.
Hosted confirmation, custom copy, or success redirect defines how the link finishes.
Hosted
Default confirmation shows the outcome clearly.
Message
Custom copy explains the next step.
Redirect
Return to your own page after success.
campaign: q2-renewal
team: enterprise-sales
reference: masked-ref
Clear product behavior, simple page language.
This showcase is not API docs, but it reflects how payment links actually work.
No. Links turn checkout into a shareable sales surface. Customers still enter hosted checkout at payment time.
Payment Links
Connect the sales conversation to payment.
Create the link, share it, collect payment, and manage completion from one product surface.