---
updatedAt: 2026-01-16T01:10:42.000Z
agentTools:
  projectIndex: https://docs.truelayer.com/llms.txt
---

# Payment configuration

All the requirements to initiate a payment, plus a guide to some of the options you have within payments requests.

## Configuration options in your request

After authenticating a payment with an access token, you can initiate a payment with an API call to the <a href="https://docs.truelayer.com/reference/create-payment" target="_blank">`/v3/payments` endpoint</a>.

When the user pays with open banking at checkout, they provide their credentials to their bank and pay over a payment scheme. To enable this to happen, you need to set up provider and payment scheme options in the payment request so your user can select a bank and payment scheme.

It's also important that you include appropriate user information in your request. The required information varies based on payment type.

### [Provider selection in the `provider_selection` object](/docs/provider-selection-for-new-returning-users)

Select which banking providers your user can choose to pay with at checkout.

You can also preselect a provider for your user. This enables you to significantly improve the returning user journey. [Learn more about how to optimise the experience for returning users.](/docs/provider-selection-for-new-returning-users#the-returning-user-flow)

### [Scheme selection in the `scheme_selection` object](/docs/select-a-scheme-for-payments)

Select which payment scheme the payment will be made through, or enable your user to select the scheme they prefer.

### [User information in the `user` object](/docs/provide-user-information-for-payments)

Pay-in and mandate requests require you to include some remitter details for security reasons. Alongside a UUID for that user, a payment request **must** include:

* Remitter name

If you are **not** regulated as a PISP, you must also include:

* Remitter email **OR** remitter phone number

If the payment is going into a merchant account, **and** you are not regulated as a PISP, you must also include:

* Remitter date of birth
* Remitter living address

## Other configuration details

There are several other things you need to consider in your integration.

### Sandbox testing

Our sandbox environment enables you to [test different payment authorisation flows for single payments](/docs/test-payments-in-sandbox) . We also have a [sandbox provider you can use to preview the VRP mandate authorisation flow](/docs/test-vrps-in-sandbox).

### [Automatic refunds](/docs/automatically-refund-payments-from-external-sources)

When you receive payments from unexpected external sources, it can expose your organisation to unnecessary risk. It can also be complex to refund payments that have been returned by a bank (for example, when a user's bank account has closed after you send a payment).

Additionally, ensuring that payments are sent as a closed-loop pay-in ensures that they work better with your integration.

You can [enable automatic refunds for your merchant account](/docs/automatically-refund-payments-from-external-sources) to ensure that payments from an external source are automatically refunded.

### [Character limitations in payments](/docs/character-limitations-in-payments)

Different banks and countries support different characters and also numbers of characters for different fields. [Learn more about restricted characters and limits](/docs/character-limitations-in-payments)  to ensure your integration works across all banks.