> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/features/payment-links-and-qrs.md).

# Payment Links and QRs

Get paid without writing a line of code – create a payment request in the Merchant Portal and share it as a link, a QR code, or a but workspaces and projects fit together, and when to create which.

Payment Links let you request and accept payments without integrating a website or checkout at all. You create a payment request in the Merchant Portal – amount, currency, description – and receive a unique, secure payment URL. Share it however you reach your customers: in an email or invoice, in a messenger chat, on social media, or as a QR code printed on a poster or shown at the counter.

When the customer opens the link, they land on the secure Hosted Checkout page operated by the gateway and pay with any payment method enabled for your shop – cards, digital wallets, or Pay by Bank. The payment is processed, tracked, and reported exactly like any other gateway transaction.

Payment Links are ideal as a first step before a full integration, as a complement to your online store for offline and social sales, and for one-off payment requests where building a checkout would be overkill.

***

### Capability Summary

<table data-header-hidden><thead><tr><th width="245" valign="top">Capability</th><th valign="top">Support</th></tr></thead><tbody><tr><td valign="top">Creation and Management</td><td valign="top">Merchant Portal (no integration required) or Merchant API</td></tr><tr><td valign="top">Link Formats</td><td valign="top">Secure payment URL, QR code, embeddable payment button code (where applicable)</td></tr><tr><td valign="top">Payment Page</td><td valign="top">Hosted Checkout with basic branding, per your white-label setup</td></tr><tr><td valign="top">Payment Methods</td><td valign="top">All methods enabled for your shop and market – cards, digital wallets, Pay by Bank</td></tr><tr><td valign="top">Configurable Parameters</td><td valign="top">Amount and currency, description or reference, validity period, single-use or reusable (where enabled), customer reference</td></tr><tr><td valign="top">Payment Tracking</td><td valign="top">Merchant Portal (Orders) and callback notifications, same as all other payments</td></tr><tr><td valign="top">Expiration</td><td valign="top">Links expire at the end of the configured validity period</td></tr><tr><td valign="top">Sandbox Testing</td><td valign="top">Available</td></tr></tbody></table>

{% hint style="info" %}
Availability of the Payment Links functionality depends on your merchant agreement, enabled payment methods, and market restrictions.
{% endhint %}

***

### How It Works

1. Create the payment request. In the [Merchant Portal](/guides/merchant-portal/accept-payments-without-integration/payment-links-and-qr-codes.md), create a new payment request and configure its parameters – the amount and currency, a description the customer will see, the validity period, and other options.
2. Get the link, QR code, or button. The gateway generates a unique, secure payment URL – together with a QR code representation and, where applicable, embeddable payment button code for your website or emails.
3. Share it with your customer. Send the link by email or messenger, include it in an invoice, post it on social media, or display the QR code wherever your customer can scan it.
4. The customer pays. The customer opens the link and lands on the secure Hosted Checkout page, where they choose from your enabled payment methods and complete the payment – including any required authentication.
5. Track the result. The payment appears in the [Merchant Portal](/guides/merchant-portal/monitor-your-business/orders.md) alongside your other transactions, and – if configured – your systems receive a callback notification. Confirm the payment status before delivering goods or services.

***

### Link Parameters

<table><thead><tr><th width="285" valign="top">Parameter</th><th valign="top">Description</th></tr></thead><tbody><tr><td valign="top">Amount and currency</td><td valign="top">The amount the customer will be asked to pay, in one of the currencies enabled for your shop.</td></tr><tr><td valign="top">Description / reference</td><td valign="top">What the payment is for – shown to the customer at checkout. Write it clearly: it is often the only context the customer has.</td></tr><tr><td valign="top">Validity period (expiration)</td><td valign="top">How long the link can be used. After expiration, the link can no longer be paid – create a new one if needed.</td></tr><tr><td valign="top">Single-use or reusable</td><td valign="top">Where enabled: a single-use link accepts one successful payment and then closes; a reusable link can accept multiple payments – for example, a standing QR code at a counter.</td></tr><tr><td valign="top">Customer reference</td><td valign="top">Optional information identifying the customer or order, to support your reconciliation.</td></tr></tbody></table>

***

### Common Use Cases

* Invoicing. Add a payment link or button to invoices sent by email – the customer pays online instead of making a manual bank transfer, and you see the payment in the Portal immediately.
* Social and messenger sales. Sell through Instagram, Facebook, WhatsApp, or other channels without a webshop – agree on the order in chat and send a link to pay.
* Remote orders. Take an order by phone or email and send the customer a link – the customer enters their own payment details on the secure Hosted Checkout page, so no card data ever passes through you.
* In-person and print QR. Print a QR code on a poster, table stand, flyer, or event badge – customers scan and pay on their own device. A reusable link (where enabled) can serve any number of customers.
* Deposits and prepayments. Request a deposit or prepayment for services, reservations, or custom orders – with an expiration that matches your offer’s validity.

***

### Customer Experience

The customer clicks the link or scans the QR code and lands on the gateway’s Hosted Checkout page, showing your shop name, the amount, and the description you provided. They choose a payment method from those enabled for your shop, complete the payment – including any authentication required by the method – and see a confirmation. The page supports basic branding in accordance with your configuration, so the experience stays recognizably yours.

If the link has expired, the customer is informed that the payment request is no longer valid – they cannot pay an expired link.

***

### Link Lifecycle and Tracking

* A link is payable from creation until the end of its validity period.
* A single-use link closes after one successful payment; a reusable link (where enabled) remains active until it expires.
* Payments made through links follow the standard payment status lifecycle – see Payment Statuses. Incomplete attempts are finalized automatically (Abandoned) and are identifiable in the Merchant Portal.
* You can generate and manage your payment links in the Merchant Portal; each resulting payment is visible under Orders with its reference information.

{% hint style="info" %}
A shared link is not a completed payment. Always confirm that the payment has reached its paid status – via the Merchant Portal or a callback notification – before delivering goods or services.
{% endhint %}

***

### What You Need

* Payment Links functionality is enabled for your merchant account – contact your SEB representative.
* At least one payment method enabled for your shop – the link offers the customer whatever is enabled.
* No technical integration is required. Optionally, configure a Callback URL to receive automatic payment status notifications in your systems.

***

### Merchant Responsibilities

The gateway provides the technical capability for generating, routing, and processing payment links. The content and use of the payment requests remain yours:

* You are responsible for the commercial content of each payment request – the description, the amount, and what the customer receives in return.
* You are responsible for communication with the customer, including sending the link, reminders, and receipts where required.
* You are responsible for compliance with marketing and consumer protection regulations applicable to how you sell.
* Distribute links through channels you control, and confirm payment status before fulfilment.

***

### Merchant Best Practices

* Write descriptions the customer will recognize – the description is your invoice line, not an internal note.
* Set the validity period to match the offer: short for quotes and reservations, longer for invoices.
* Use single-use links for individual orders and reusable links only where multiple payments are genuinely intended.
* Use the customer reference field so every payment can be matched to an order or customer without guesswork.
* Never ask customers to send card details in chat or by phone – the whole point of the link is that they enter payment details only on the secure hosted page.

***

### Frequently Asked Questions

<details>

<summary>Do I need a website or an integration to use Payment Links?</summary>

No. Links are created and managed entirely in the Merchant Portal, and the customer pays on the Hosted Checkout page. A Callback URL is optional – useful if you want payment confirmations delivered to your systems automatically.\
Links can also be created and managed programmatically via the Merchant API – see Pay by Link API

</details>

<details>

<summary>Which payment methods can the customer use?</summary>

All payment methods enabled for your shop and market – cards, digital wallets, and Pay by Bank – subject to regulatory, scheme, and technical constraints. The customer chooses the method on the Hosted Checkout page.

</details>

<details>

<summary>Can the same link be paid twice?</summary>

A single-use link accepts one successful payment and then closes. A reusable link – where enabled for your account – can accept multiple payments until it expires. Choose the type that matches your scenario.

</details>

<details>

<summary>What happens when a link expires?</summary>

The link can no longer be paid, and the customer is informed that the payment request is no longer valid. Create a new link if the customer still wants to pay – expired links are not reactivated.

</details>

<details>

<summary>How do I know the customer has paid?</summary>

Check the payment status in the Merchant Portal under Orders, or receive a callback notification if you have configured a Callback URL. Rely on the payment status – not on the customer’s confirmation – before delivering goods or services.

</details>

<details>

<summary>Can I refund a payment made through a link?</summary>

Yes. Payments made through links are standard gateway transactions – refunds follow the rules of the payment method used, and can be initiated the same way as for your other payments.

</details>

### Related Documentation

* [Merchant Portal](/guides/merchant-portal/accept-payments-without-integration/payment-links-and-qr-codes.md)
* Cards [Payment Statuses](/payment-methods/cards/payment-statuses.md)
* Pay by Bank [Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md)
* [Callback Notifications](/integration/merchant-api/webhooks.md)
* [Refunds](/features/refunds.md)
* [Payment Methods](/payment-methods/cards.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ecommerce.seb.ee/features/payment-links-and-qrs.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
