> 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/additional-fields.md).

# Additional Fields

Collect the additional information your business needs when customers pay through Payment Links.

Additional Fields let you add merchant-specific information to a payment request without changing the standard payment flow. Use them to attach your own reference data to a transaction or ask the customer for additional information during Hosted Checkout.

For example, you can use Additional Fields  for an order reference, booking number, participant name, delivery instruction, or another detail required to process the purchase.

{% hint style="info" %}
Availability and management rights depend on your merchant configuration and the permissions assigned to your Merchant Portal user.
{% endhint %}

### Capability Summary

<table><thead><tr><th width="260">Capability</th><th>Support</th></tr></thead><tbody><tr><td>Field management</td><td>Create, activate, and manage Additional Fields </td></tr><tr><td>Payment Link association</td><td>Attach one or multiple fields to a Payment Link</td></tr><tr><td>Merchant-provided values</td><td>Pre-fill a field when creating the Payment Link</td></tr><tr><td>Customer-provided values</td><td>Ask the customer to enter a value during checkout</td></tr><tr><td>Required fields</td><td>Mark a field as mandatory</td></tr><tr><td>Validation</td><td>Configure supported rules, such as minimum and maximum length</td></tr><tr><td>Customer-facing labels</td><td>Configure multilingual field labels</td></tr><tr><td>Checkout display</td><td>Fields are rendered within Hosted Checkout</td></tr><tr><td>Transaction data</td><td>Store merchant-provided values as transaction metadata</td></tr><tr><td>Historical records</td><td>Later field changes do not modify existing transactions</td></tr></tbody></table>

***

### How Additional Fields Work

An Additional Field is defined separately and then associated with a Payment Link.

A typical flow is:

1. [**Create the field**](/guides/merchant-portal/accept-payments-without-integration/payment-links-and-qr-codes.md)**.** Define the additional information you want to collect or attach to a payment.
2. **Configure the label.** Enter the customer-facing field label, including multilingual versions where required.
3. **Activate the field.** Only active fields can be used with new Payment Links.
4. **Attach it to a** [**Payment Link.**](/guides/merchant-portal/accept-payments-without-integration/payment-links-and-qr-codes.md) Select one or multiple Additional Fields when creating the link.
5. **Choose the field behaviour.** Pre-fill the value yourself or ask the customer to provide it during checkout.
6. **Collect the payment.** The configured field is displayed in Hosted Checkout, and the value is associated with the resulting transaction.

{% hint style="info" %}
Additional Fields supplement the standard payment information. They do not modify the payment amount, payment methods, authentication process, or other payment-processing logic.
{% endhint %}

***

### Field Behaviour

Configure how each Aditional Field behaves for the Payment Link to which it is attached.

| Field behaviour         | How it works                                                                                               | Example                                                   |
| ----------------------- | ---------------------------------------------------------------------------------------------------------- | --------------------------------------------------------- |
| Merchant-provided value | You enter the value when creating the Payment Link. The value is stored as transaction metadata.           | Internal order number, contract reference, campaign code  |
| Customer-provided value | The field is displayed in Hosted Checkout and the customer enters the value before completing the payment. | Participant name, delivery instruction, booking reference |

The available behaviour is configured separately for each field–link association.

The Service checks the configuration and prevents logically incompatible field settings from being used together.

***

### Required Fields and Validation

A customer-facing field can be marked as mandatory. Use required fields only when the information is necessary to process or fulfil the order.

Additional Fields can also apply supported validation rules, such as:

* Minimum character length
* Maximum character length

Validation helps keep the collected data consistent and prevents incomplete or incorrectly formatted values.

{% hint style="info" %}
Validation rules apply only to new customer input. They do not change values stored in historical transactions.
{% endhint %}

***

### Multilingual Labels

Customer-facing Additional Fields support multilingual display labels.

Use a short and clear label that explains exactly what the customer should enter. Provide the applicable label translations so the field remains understandable when Hosted Checkout is displayed in another supported language.

For example:

<table><thead><tr><th width="176">Language</th><th>Label</th></tr></thead><tbody><tr><td>English</td><td>Booking reference</td></tr><tr><td>Estonian</td><td>Broneeringu viide</td></tr><tr><td>Latvian</td><td>Rezervācijas atsauce</td></tr><tr><td>Lithuanian</td><td>Rezervacijos numeris</td></tr></tbody></table>

The examples above illustrate how multilingual labels may be structured; the actual wording remains your responsibility.

{% hint style="info" %}
Avoid using internal terminology that customers might not understand. For example, prefer **Booking reference** to an internal abbreviation such as **BKG\_REF**.
{% endhint %}

***

### Common Use Cases

Additional Fields can support different operational and reconciliation needs.

#### Connect a Payment to an Internal Record

Pre-fill an internal order, account, booking, or contract reference when creating the Payment Link. The reference is stored with the transaction and can help your teams match the payment to the correct business record.

#### Collect Fulfilment Information

Ask the customer for information needed to complete the purchase, such as a participant name, requested delivery instruction, or service reference.

#### Support Different Payment Link Scenarios

Attach different fields to different Payment Links. For example, an event payment might request the attendee’s name, while a service payment might include a merchant-provided contract reference.

{% hint style="info" %}
Only collect information that is directly relevant to the purpose of the payment.
{% endhint %}

***

### Managing Field Changes

Changes to an Aditional Field apply prospectively.

Updating a label, validation rule, or other field definition affects its future use but does not modify historical transaction records. Previously collected values remain associated with the transactions under which they were submitted.

Before changing a field that is already in use, consider whether:

* Existing Payment Links use the field.
* The updated label still has the same meaning.
* The validation rules remain compatible with expected values.
* Your operational or reconciliation processes depend on the previous configuration.

Create a separate field instead of repurposing an existing one when the new field has a materially different meaning.

***

### Data Protection and Security

{% hint style="warning" %}
**Do not use Additional Fields to collect payment credentials or sensitive authentication data.**

Never request card numbers, CVV/CVC codes, PINs, passwords, or online banking credentials through a Custom Field.
{% endhint %}

Collect only the information necessary for the specific payment and clearly explain why it is required. This follows the GDPR principle that personal data should be relevant and limited to what is necessary. Leading payment platforms apply the same caution to custom checkout fields, while PCI DSS prohibits retaining card verification codes after authorization.

You are responsible for:

* Determining which information should be collected.
* Having an appropriate legal basis when the field contains personal data.
* Providing clear and accurate field labels.
* Protecting and using the collected information appropriately.
* Avoiding unnecessary collection of confidential or sensitive information.
* Ensuring that field content complies with applicable laws and your privacy policy.

***

### Merchant Best Practices

* **Keep labels clear.** Tell the customer exactly what value is expected.
* **Collect only what you need.** Every additional field increases checkout effort.
* **Use required fields selectively.** Do not block payment for information that can be collected later.
* **Apply sensible validation.** Set limits that reject invalid input without preventing legitimate values.
* **Use merchant-provided fields for internal references.** Do not ask customers to enter information already known to your systems.
* **Use consistent field meanings.** Do not reuse one field for unrelated purposes.
* **Review translations.** Make sure every label has the same meaning in each supported language.
* **Test the customer experience.** Check that fields appear correctly and remain easy to complete on both desktop and mobile devices.

***

### Frequently Asked Questions

<details>

<summary>What is an Aditional Field?</summary>

An Aditional Field is an additional merchant-defined data field associated with a Payment Link. It can contain a value provided by you or request information from the customer during checkout.

</details>

<details>

<summary>Can I add more than one Aditional Field to a Payment Link?</summary>

Yes. One or multiple Additional Fields can be associated with a Payment Link, subject to the limits and configuration available in the Service.

</details>

<details>

<summary>Can I enter the value myself?</summary>

Yes. A value can be pre-filled when the Payment Link is created. The value is then stored as transaction metadata.

</details>

<details>

<summary>Can an Aditional Field be mandatory?</summary>

Yes. Customer-facing fields can be marked as required.

</details>

<details>

<summary>Can I validate the information entered by the customer?</summary>

Yes. Supported validation rules include minimum and maximum character length. The exact available options depend on the field configuration supported by the Service.

</details>

<details>

<summary>Can field labels be translated?</summary>

Yes. Additional Fields support multilingual labels for customer-facing fields.

</details>

<details>

<summary>What happens if I change a field?</summary>

The change applies to future use. Historical transaction records and previously collected values are not modified.

</details>

<details>

<summary>Can I use Additional Fields to collect card details?</summary>

No. Payment credentials and sensitive authentication data must be collected only through the designated secure payment components. Never use Additional Fields for card numbers, CVV/CVC codes, PINs, passwords, or banking credentials.

</details>

### Related Documentation

*
* [Payment Links and QRs](/features/payment-links-and-qrs.md)
* [Hosted Checkout](/integration/hosted-checkout.md)
* [Payment Methods](/payment-methods/cards.md)
* Cards [Payment Statuses](/payment-methods/cards/payment-statuses.md)
* Pay by Bank [Payment Statuses](/payment-methods/pay-by-bank/payment-statuses.md)
* [Merchant Portal](/guides/merchant-portal.md)
* [Orders](/guides/merchant-portal/monitor-your-business/orders.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/additional-fields.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.