Skip to main content
Ideal for: Collecting payments without a website or a checkout integration — donations, invoices, social selling, event tickets. You create a link once and share it; anyone who opens it can pay. Both send the customer to a SeerBit-hosted page to pay, so the difference is not the payment experience — it is when the link is created and how many times it can be used. In short: Standard Checkout creates a link for one customer, one purchase, at the moment of purchase. A payment link is created once and works for everyone until you turn it off. If your application already knows the amount and the customer at the point of payment, use Standard Checkout. If you are sending a request to pay — or selling somewhere you have no checkout at all — use a payment link.
Need line items, a due date and a document? That is an invoice, not a payment link — SeerBit emails it to a named customer and gives it an invoice number you can look up. See the comparison.

How it works

You create a link through the API (or your dashboard) with a name, a currency and the fields you want to collect. SeerBit returns a paymentLinkUrl you can share anywhere. When a customer opens it they see a SeerBit-hosted payment page, pay with any method enabled on your account, and the transaction appears in your dashboard like any other. Links can be one-time or reusable, can expire on a date, and can let the customer enter the amount themselves — useful for donations.

Authentication

Payment Link calls are authenticated with a bearer token, generated from your public and secret keys.

Authentication

How to generate the token, and which credential every other SeerBit API expects.
POST

Request Sample

The code snippet below shows an example request for creating a payment link

Response Sample

The code snippet below shows an example response for creating a payment link

Parameter description

requiredFields object
Set a field to true to make the customer enter it before paying.

Response fields

Note: Required-flag values above are derived from the request samples on this page. Confirm against the API Reference before relying on a field being optional.
GET

Request Sample

The code snippet below shows an example request for getting merchant payment link

Response Sample

The code snippet below shows an example response to get all created links
PUT

Request Sample

The code snippet below shows an example request for updating a payment link

Response Sample

The code snippet below shows an example response for updating a payment link
DELETE

Response Sample

The code snippet below shows an example response for deleting a payment link

Notes

  • Share the paymentLinkUrl, not the paymentLinkId. The URL is the customer-facing address; the ID is for managing the link through the API.
  • A reusable link produces many transactions. Reconcile on the transaction reference returned per payment, not on the link itself.
  • Deactivating is not deleting. Setting status to INACTIVE stops payments while keeping the link’s history; deleting removes it.
  • Confirm every payment server-side before you fulfil — see Verify a payment.
  • Links created with test keys only work in test mode. See Test and live modes.