A general payment link is created once and paid by many people. There is no fixed customer, and the currency is chosen at checkout rather than when you create the link.

Use it for donation pages, generic payment requests, event tickets, and anywhere you publish a single "pay here" URL.

The extra step compared with a normal payment link: because the customer is unknown, checkout collects their email and currency before payment can start.

The Flow

sequenceDiagram
    participant Y as Your backend
    participant K as Kyshi
    participant C as Customer

    Y->>K: POST /v1/pay/general
    K-->>Y: paymentLink.url + code
    Y->>C: Publish the link
    C->>K: Opens link
    K-->>C: Currencies + line items
    C->>K: Checkout (email + currency)
    K-->>C: Checkout URL
    C->>K: Pays
    K-->>Y: Webhook charge.success
    Y->>K: GET /v1/pay/general/verify/{code}

Build It

1. Create the link

-H "x-api-key: your_secret_key"

POST {{host}}/v1/pay/general

Create it once and reuse the returned paymentLink.url. You do not create a new link per payer.

2. Verify before showing checkout

GET {{host}}/v1/pay/general/verify/{code}

Call this when the customer opens the link, so your UI shows the currencies and line items that are valid now rather than when the link was created. Rates and availability move.

3. Check out

The customer supplies their email and chooses a currency. Kyshi returns a checkout URL for that specific payment.

Each payment through the link is its own transaction with its own reference. The link is a template, not a payment.

4. Verify before fulfilling

Act on charge.success, then verify the transaction before releasing anything.

When It Fails

Treating the link as one payment

The link persists and accumulates payments. Reconcile per transaction, not per link — a link with one SUCCESS may have ten more tomorrow.

No way to tell payers apart

With no fixed customer, the only identity you get is what checkout collects. If you need to know which order or supporter a payment belongs to, either capture it at checkout or use a per-customer Payment Link instead.

Publishing one general link for many distinct obligations makes reconciliation guesswork.

Amounts drift between payers

The payable amount is recalculated at the rate current when each customer pays, so two people paying on different days may be charged different local amounts for the same link. Expected — but say so on the page if it will surprise anyone. See FX And Rates.

The link is paid after you stopped expecting it

A published URL keeps working. Retire links you no longer want paid rather than assuming nobody will find them.

Reconcile

Reconcile the transactions the link produced, not the link:

GET {{host}}/v1/transactions/history

Filter to the period you are closing and match each transaction by its own reference. See Retrieve Transaction History.

Test It

1. Two different customers pay the same link and produce two distinct transactions.
2. Each fulfils exactly once.
3. Verification before checkout returns current currencies.
4. A stale cached currency list does not break checkout.

Next

• Create General Payment Link · Checkout · Verify
• Payment Links — when you know the customer