# Payment links A payment link is a hosted checkout page you create in the dashboard and share as a URL or QR code. A customer opens it, pays with MTN or Orange Mobile Money, and the money is collected into your Kwik Nkap balance. No code required. B[Shares URL or QR code] B --> C[Customer opens hosted checkout] C --> D[Pays by Mobile Money MTN or Orange] D --> E[Collection settles into merchant balance] `} /> :::note Payment links can be created **either** in the dashboard ([app.kwiknkap.com](https://app.kwiknkap.com)) **or** through the public API with your `kn_sk_test_` / `kn_sk_live_` key — see [Payment links in the API reference](/en/api/payment-links). The API supports the full lifecycle: create, retrieve, list, update, deactivate and delete. One difference matters: a link created **through the API** carries your API key, so payments on it emit webhooks to your endpoints. A link created **in the dashboard** does not, so you will not receive integrator webhooks for it. ::: ## What a payment link is A payment link turns a fixed amount, a product, or a donation ask into a single shareable page hosted at `pay.kwiknkap.com`. Each link has a unique short code, so the public URL looks like: ```text https://pay.kwiknkap.com/payment-links/{shortCode} ``` You can share that URL anywhere (WhatsApp, social bio, SMS, email) or download a generated QR code PNG that resolves to the same page. The customer never needs a Kwik Nkap account, and you never need to build a checkout. The amount is collected over Mobile Money straight into your merchant balance, in XAF. Use a payment link when you want to: - Sell a single product or service without standing up a full storefront. - Collect a donation or contribution toward a fixed or open amount. - Take a deposit or one-time fee. - Offer a few pricing options (variants) or quantity-based pricing for the same item. ## Anatomy of a link When you create a link in the dashboard you configure the following: | Setting | Description | | --- | --- | | Title | The name shown on the checkout page. Required. | | Description | Optional supporting text shown to the buyer. | | Amount | The base price to collect, in whole XAF francs. | | Currency | Defaults to **XAF**. No minor units, no x100 — `5000` means 5,000 francs. | | Cover photo | An optional header image for the page. Mirrored into your business media gallery. | | Gallery images | Optional additional images. | | Required fields | Optional customer fields (for example name, email, a note) the buyer must fill before paying. | | Variants | Optional product options, each with its own price (tiered pricing). | | Quantity / tiered pricing | Optional price that resolves from the selected quantity or tier. | | Expiry | An optional date after which the link stops accepting payments. | | `allowMultiplePayments` | Whether the link can be paid more than once (reusable) or only once (one-off). | | `maxPayments` | An optional cap on how many successful payments a reusable link will accept. | ### Fixed amount vs variants and tiers A simple link collects one fixed `amount`. If you sell a few options of the same thing (sizes, ticket tiers, contribution levels), add **variants** — each variant carries its own price, and the customer picks one at checkout. **Quantity / tiered pricing** resolves the final price from how many units the customer selects. If you allow a custom amount (for example a donation), the buyer enters their own value, validated against any configured min/max. The final amount charged is always resolved server-side at pay time from the base amount, the selected variant, the quantity tier, or a validated custom amount — never trusted from the client. ### One-off vs reusable links Two settings control how many times a link can be paid: - **One-off** — leave `allowMultiplePayments` off. The link accepts a single successful payment, then stops being payable. Good for a specific invoice-like ask or a one-time deposit. - **Reusable** — turn `allowMultiplePayments` on. The same link can be paid by many customers. Optionally set `maxPayments` to cap the total number of successful payments (for example a limited drop). Without a cap it accepts payments indefinitely while active and unexpired. ## Creating a link from the dashboard 1. Open the dashboard at [app.kwiknkap.com](https://app.kwiknkap.com) and go to **Payment links**. 2. Fill in the title, description, and base amount (currency defaults to XAF). 3. Upload a cover photo and gallery images if you want a richer page. 4. Add any **required fields** the buyer must complete. 5. Add **variants** or **tiered/quantity pricing** if you sell options of the same item. 6. Set an **expiry** date and choose **one-off** or **reusable** (`allowMultiplePayments`, optional `maxPayments`). 7. Save. The link is created **ACTIVE** with a unique short code. 8. Open the **Share** tab to copy the URL, open the page, or download the QR code. :::tip A payment link can also be attached to a published storefront. When the link belongs to a storefront, the checkout renders the storefront product page instead of the standalone view. See [Storefronts & events](/en/products/storefronts). ::: ## The hosted checkout experience When a customer opens `pay.kwiknkap.com/payment-links/{shortCode}`, the page loads the link's data and computes whether it is currently **payable** based on its status, expiry, and payment-count limits. The customer then: 1. Reviews the title, description, images, and amount. 2. Fills any **required fields** you configured. 3. Selects a **variant** or **quantity** if the link offers them; the price resolves accordingly. 4. Enters their **phone number** and selects an **operator** (MTN or ORANGE). 5. Submits the payment. If the link is inactive, expired, or has hit its payment limit, the page shows that it is no longer accepting payments instead of a pay form. ## How a paid link becomes a collection Submitting the checkout triggers a Mobile Money **collection** — the same collection primitive that backs the rest of the platform, including the public [Payments & Collections](/en/payments/overview) API. When the customer submits: 1. The backend validates payability and required fields, then resolves the final amount. 2. It initiates a Mobile Money collection and records a payment against your business, linked to a collection transaction. The payment starts **PENDING**. 3. The customer receives a Mobile Money prompt (MTN MoMo or Orange Money) on their phone and approves the debit with their PIN. 4. When the provider settles, the collection resolves to **SUCCESS** or **FAILED**. On success, the funds land in your Kwik Nkap business balance (net of the application fee), in XAF. 5. The checkout polls the payment status until it settles, then optionally redirects to your configured success URL. Payout of your settled balance to Mobile Money is handled by the platform's standard disbursement flow, not by payment links. :::info Payment links use Mobile Money only (MTN / Orange). There are no card rails, and the currency is always XAF. ::: ## Link statuses and payability A link's status controls whether the hosted page accepts payments: | Status | Meaning | | --- | --- | | ACTIVE | The default on creation. The link accepts payments (subject to expiry and limits). | | INACTIVE | The link is disabled and will not accept payments. | | PAUSED | Temporarily suspended; not currently accepting payments. | | EXPIRED | The link's expiry date has passed. | Beyond status, a link is only **payable** if it has not expired and has not reached its payment limit (`maxPayments` on a reusable link, or the single payment on a one-off link). Individual payments against a link follow the collection lifecycle: **PENDING → SUCCESS** or **FAILED**, matching the status model of the public Payments API. See [Payment status](/en/api/direct-payments). ## Tracking results From the dashboard you can track each link's performance: - **Stats** — total collected and payment count for the link, so you can see views-to-payments conversion at a glance. - **Transactions** — the per-link list of collection transactions, each with its own status (PENDING / SUCCESS / FAILED), so you can reconcile individual payments. You can also **edit**, **pause or deactivate** (status), **duplicate**, or **delete** a link at any time. Deactivating a reusable link stops new payments without affecting already-settled ones. ## Relationship to the public API The hosted checkout pages at `pay.kwiknkap.com` are public browser pages your customers open — they are not API endpoints and take no API key. The **management** of links (create, update, deactivate, delete) is fully API-driven; see [the reference](/en/api/payment-links). If you need to collect Mobile Money payments programmatically today, use the public [Payments & Collections](/en/payments/overview) API: `POST /v1/payments` creates the same kind of collection directly from your server. Payment links wrap that collection engine in a no-code, shareable page, and exposing them on the public API is planned for the future. ## Next steps - [Payments & Collections](/en/payments/overview) — collect Mobile Money payments programmatically. - [Invoices](/en/products/invoices) — itemized bills paid by Mobile Money. - [Storefronts & events](/en/products/storefronts) — hosted shops and event ticketing that can host payment links. - [Webhooks](/en/payments/webhooks) — react to `payment.success` and `payment.failed` on settlement.