> For the complete documentation index, see [llms.txt](https://wallee.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wallee.gitbook.io/documentation/payments/integrations/features/payment-links.md).

# Payment Links

Payment Links let you collect payments without a backend system or ecommerce platform. A public URL or QR code is provided—sharing it initiates the payment flow.

Payment links let you collect payments without a backend system or e-commerce platform. You create a link in your space, share the URL or QR code, and the customer completes the payment on a hosted payment page.

There are two ways to work with them:

* **Configure everything in your space** — currency, payment methods, validity and the amount are fixed in the link itself. Share the URL or QR code and you are done.
* **Pass details in from your own form** — a lightweight HTML form on your website supplies billing addresses, line items or amounts per payment. No server-side logic required.

### Common use cases

* **Static product pages** — for example flash sales or landing pages
* **Donation pages** — with dynamic or fixed amounts
* **Embedded forms** on websites without backend logic
* **Simplified payment processes** for individual purchases

{% hint style="info" %}
If you need to manage reminders or send payment links via email automatically, consider using Charge Flows instead.
{% endhint %}

### How to enable payment links in your {inject-platform-name}

1. Open your [space settings](https://{inject-platform-url}/select?target=/space/settings).
2. Click **Features** and enable the **Payment Link** toggle.
3. Save the changes.

### How to create a payment link

1. Open the [payment link list](https://{inject-platform-url}/select?target=/payment/link/list) in your space.
2. Click **Create payment link**.
3. Enter a **name**.
4. Configure the options below and click **Create**.

| Option                                       | What it controls                                       |
| -------------------------------------------- | ------------------------------------------------------ |
| **Currency**                                 | The currency the payment is collected in.              |
| **Language**                                 | The language of the payment page.                      |
| **Protection mode**                          | Whether a key is required to access the payment link.  |
| **Allowed payment method configurations**    | Which payment methods the customer can choose from.    |
| **Available from / until**                   | The date and time window in which the link is valid.   |
| **Maximal number of transactions**           | How many payments may be made through the link.        |
| **Billing / shipping address handling mode** | Whether addresses are requested, prefilled or skipped. |

{% hint style="info" %}
Only the **name** is mandatory — every other option is optional. Defining as much as possible in the link is nevertheless a good idea: values that are not fixed in the link can be supplied (and therefore changed) in the request.
{% endhint %}

After creating the link, you are shown:

1. A **public URL** that you can share via email, social media and similar channels.
2. A **QR code** for print or in-person use.

***

### Passing parameters from your own form

Instead of fixing everything in the link, you can submit payment details with the request. Payment links accept GET or POST parameters — we recommend POST — that include billing addresses, amounts or line items.

### Quick setup checklist

1. **Create a payment link** under **Space > Payment Links > Create**. Give the link a name and optionally predefine values such as currency or line items to prevent tampering.
2. **Embed the link** — use the generated URL in a POST form on your website and pass additional parameters, such as the billing address, dynamically if needed.
3. **Secure and validate** — avoid GET requests to prevent URL size issues, use address validation for a better experience, and predefine as much as possible in the link to restrict what the buyer can modify.

### Example HTML form

```html
<form action="<< put here payment link url >>" method="POST">

	<input type="text" name="billingAddress[givenName]" placeholder="Given Name" />
	<input type="text" name="billingAddress[familyName]" placeholder="Family Name" />
	<input type="text" name="billingAddress[street]" placeholder="Street" />
	<input type="text" name="billingAddress[postcode]" placeholder="Postcode" />
	<input type="text" name="billingAddress[city]" placeholder="City Name" />
	<input type="text" name="billingAddress[country]" placeholder="Country Code" />

	<input type="hidden" name="lineItems[0][uniqueId]" value="test" />
	<input type="hidden" name="lineItems[0][sku]" value="test" />
	<input type="hidden" name="lineItems[0][name]" value="Test" />
	<input type="hidden" name="lineItems[0][amountIncludingTax]" value="10.87" />
	<input type="hidden" name="lineItems[0][type]" value="PRODUCT" />
	<input type="hidden" name="lineItems[0][quantity]" value="1" />

	<input type="hidden" name="metaData[additionalData]" value="Further data you want to store along the transaction." />

	<input type="hidden" name="currency" value="CHF" />

	<!-- Further parameters as you need. -->

	<input type="submit" value="Pay" />
</form>
```

{% hint style="info" %}
Use the `POST` method to avoid length restrictions and to handle parameters more securely.
{% endhint %}

### Parameters

Payment links accept the same parameters used in our transaction creation API — see Web Service API. Parameters must be submitted in UTF-8 and follow the key-value format supported by HTML forms.

#### Billing and shipping address

Use `billingAddress[...]` and `shippingAddress[...]` to provide:

* `country` (ISO 3166-1 alpha-2, required)
* `givenName`
* `familyName`
* `street`
* `postcode`
* `city`

#### Customer information

* `customerEmailAddress` — used to send confirmation emails.

{% hint style="warning" %}
`customerId` is ignored: it is not supported for payment links, and neither are one-click payments (see below).
{% endhint %}

#### Line items

Minimum required per line item:

* `lineItems[0][amountIncludingTax]`
* `lineItems[0][name]`
* `lineItems[0][quantity]`
* `lineItems[0][type]` — for example `PRODUCT`, `SHIPPING` or `DISCOUNT`
* `lineItems[0][uniqueId]`

Additional fields such as taxes, attributes or SKUs are supported.

{% hint style="warning" %}
If you pass line items in the form request instead of predefining them in the payment link, they can be modified by the buyer. The same applies to the merchant reference.
{% endhint %}

#### Currency

* `currency` — for example `CHF`, `EUR` or `USD`.

If the currency is not defined in the payment link, you must include it in the request.

#### Redirect URLs

* `successUrl` — where the customer is redirected after a successful payment.
* `failedUrl` — where the customer is redirected after a failed payment.

{% hint style="info" %}
Use **absolute URLs** such as `https://example.com/thank-you`, not relative ones.
{% endhint %}

#### Merchant reference

* `merchantReference` — shown in the transaction overview and used for searches.

#### Meta data

* `metaData[key] = value` — stores additional key-value data along the transaction.

Example:

```html
<input type="hidden" name="metaData[comment]" value="Order from newsletter campaign" />
```

#### Availability window

* `availableFrom` — for example `2025-01-01T00:00:00Z`
* `availableUntil` — for example `2025-01-07T23:59:59Z`

{% hint style="info" %}
The availability window is only enforceable if it is configured directly in the payment link, not if it is passed through the form.
{% endhint %}

### Validation best practices

* Use **client-side address validation** to improve the experience and reduce errors.
* We always validate form data server-side before processing.
* Errors are displayed on a fallback error page, which is not ideal for the user flow — catching problems in your own form first gives the better experience.

### Terms and conditions

If required, add a checkbox to your form so the customer confirms your terms and conditions.

For a stronger guarantee, use the **Terms & Conditions add-on**, which enforces acceptance on the payment page itself.

### Why one-click payments are not supported

Payment links do **not** support one-click payments, because:

* we do not authenticate users, and
* payment credentials cannot be reused securely without authentication.

Even if one-click is enabled on a payment method, it is ignored when the payment is made through a payment link. See Tokenization for the integrations where one-click is available.

### Related topics

* [Charge Flows](/documentation/payments/integrations/features/charge-flows.md) — if you need automatic reminders or want the link sent by email for you.
* [Transaction States](/documentation/payments/overview/transaction-states.md) — what happens after the customer pays.
* [Checkout Integrations](/documentation/payments/integrations/integrations.md) — the other ways a customer can pay.