Payment configuration
Payment configuration
Seamless checkoutsFor more information on payments in general, as well as an explanation of integrated and non-integrated (custom) payment parties, see Payments under Concepts.
The Payment methods chapter gives you a clear overview of all different payment methods, such as Adyen, AdyenCheckoutAPI, EVAPay or Mollie, followed by the payment types available for that method. For example, the AdyenCheckoutAPI payment method includes the payment types, iDeal, Apple Pay, Credit Card, etc.
Now, several payment methods will come preconfigured in your environment. Those are non-editable, and are found under the System card. Custom payment methods on the other hand, those are found and/or created/edited via the second card in this overview, called Custom.
In order to be able to access this chapter, you need the PaymentMethods and PaymentTypes permissions.
Make use of the right pane filters to narrow down your overview results. The filter fields will differ along with the chosen tab (Payment methods, Payment types and Setting). The filters offer options relevant to its kind.
Creating/editing a custom payment method
You can add a custom payment method by clicking the '+' icon in the top right of the Custom card. The required fields are Name and Code. The code, when creating a new payment method, is not used in its configuration and serves more as an indicative field than anything else.
On the other hand, editing is as simple as clicking the 'pencil' icon.
Creating a System payment method or editing an existing one is not possible. We'll take care of that when and if required.
Adding/editing a payment type
You can add a new payment type from the Payment types tab by clicking the '+' icon in the top right of the card.
The fields used in creation of a payment type and their descriptions are as follows:
- Payment method: A dropdown list based on the available System and configured Custom Payment methods.
- Name: The name of the payment method, specifically how it will be displayed.
- Code: The internal reference code for system to system communication.
More about the Code
The payment method determines the required entry for the Code field, as the code must align with the PSP's internal reference. For instance, using the ADYEN_CHECKOUT_API payment method necessitates a code format specified by Adyen, like ADYEN_CHECKOUT_API_BRANDNAME.
In this format, BRANDNAME refers to Adyen's code for integrating with another payment provider, such as iDeal in the Netherlands. For iDEAL, the code would typically be ADYEN_CHECKOUT_API_IDEAL.
More about integrating with Adyen here.
- Backend ID: BackendID of the payment type.
- Return method: Define what action should be taken when an order is returned with payments on it.
- Default -> a return order that is triggered by a user
- Blocked -> the order can't be returned.
- Forced -> automatically create refunds for these payments.
- Payment category: Payment categories are set for compliancy reasons: aside from the Other category, these don't affect your payment directly, but instead allow you to designate the payments as one of the generic categories as used by the fiscal printers and in the from the Audit files.
- Other = 0 (using this makes it an invalid payment type)
- Debit = 1
- Credit = 2
- Cash = 3
- Voucher = 4
- Online = 5
- Rounding = 6.
- Active: Enable/disable the payment type.
- Script: Select an active PaymentTypeAvailability script, to fine-tune this payment method's availability based on order properties.
General details
Those are the details that were initially filled in at time of creation.
A description of each field can be found here.
Options
This card may differ based on whether the payment method is System, Custom, or Loyalty. A custom one will show more fields. Nonetheless, all fields will contain a dropdown with options to choose from, most are quite straight forward. Here are a few:
- Filtered roles: Determines the roles that this payment type could be used by. Only those selected will be the ones able to see and use this payment type.
- Cash journal method: This field is used for payment types that have some physical representation, mostly that's just cash. This field will determine when the cash journal for such payment type should be counted in your store (organization unit), with the following possible variations available:
- None: no cash journal
- Close: only when closing the journal
- OpenAndClose: when opening or closing the journal
- Ignore: the employee never counts it, but there is a journal that is automatically set with the right amounts
- Payment settings: Your selection here impacts the behavior when a payment transaction is made using this type.
Expand for Details
| Property | Description |
|---|---|
| Pending confirmation | Determines if payment attempts using this payment type would require a manual approval or not. Selecting this would mean that any payment transaction performed using this payment type would always get the status Pending and need to be approved manually. |
| Refunds allowed | Determines if this Payment type can be used for refund transactions. Selecting this would mean that any refund attempts using this payment type are allowed. |
| Refunds pending confirmation | Determines if refunds attempts using this payment type would require a manual approval or not. Selecting this would mean that any refund transaction performed using this payment type would always get the status Pending and need to be approved manually. |
| Refund without original order | Determines if refund attempts are allowed without an original payment transaction. Selecting this would mean a yes. |
| Cancellations allowed | Determines if payment transactions using this type can be cancelled. Selecting this would mean a yes. |
| Requires confirmation for payments | Displays a modal to let employees verify if the payment was successful; if it is not, another payment method can be selected. |
| Requires confirmation cor refunds | Displays a modal to let employees verify if the refund was successful; if it is not, another refund method can be selected. |
| Requires amount | Requires the user to specify an amount. |
| Only refunds | Determines if this payment type can be used to perform payments. This is used for instance when combined with Refunds allowed. Making the payment type only available for refunds but not for payments. |
| Auto finalize on paid order | Selecting this will move the App user during a payment flow automatically to the documents page after payment is performed i.e. not having to use the Proceed button. |
| Print on documents | Determines whether the used payment type will be printed on the invoice/receipt or not. Selecting this would mean to print on the documents. |
- Required user role: Makes the payment type exclusively available to users with a certain user type.
- Required functionality: Makes the payment type exclusively available to users with a certain functionality.
Options if a Loyalty Payment Method was Selected
This payment method card named Loyalty is specifically meant for your loyalty payment types. It is mostly similar to the regular payment types, aside from that it features a Loyalty program ID field in its Options card.
For example, users can link their LINE accounts to their customer accounts, enabling full, partial or mixed payments using a loyalty payment type.
Options if a Custom Payment Method was Selected
As you can see, the options for custom payment methods also include setting a Required user role and a Required functionality, the latter of which is an entire list of functionalities - type what you're looking for.
Even though the first four fields are the same as for a regular payment method, the possible values of the fields differ: custom payment methods once again offer more values. This includes how to handle refunds, cancellations, confirmations, etc; a host of configuration options are available to custom payment methods.
Keep in mind that some options work in tandem. Take for example Only refunds, which will not be effective if Refunds allowed and Refund without original order are not set.
Organization unit settings
You can add more configuration options to OU sets. These options include for example a specific Capture moment or disabling for certain line action types.
For backwards compatibility reasons, all types are available across organization units regardless of specified sets by default.
The recommended configuration however, is to make use of the PaymentMethods:PaymentTypeAvailabilityByOuSetType setting. By setting this to true on root level, availability is strictly limited to the specified OU sets.
This allows for much more fine-grained structures, such as having CASH available for a store set only (so it's not available on ecom).
- Refund priority: The Refund priority is set by entering any number - the higher the number, the higher the priority.
- Capture moment: The Capture moment determines if and when EVA would send a capture request towards the PSP, make sure the systems have a matching moment. When not specified it will default to None. The dropdown offers the following options:
- None: direct capture moment (such as when using PIN in store)
- Manual: manual action required
- Ship: when the order is shipped
- Confirmation: as soon as the order is confirmed
- Authorization expiration days: This can only be filled if the Capture moment was set to any value other than None. This specifies the number of days after which any uncaptured payment amounts will be automatically cancelled. Just like with the capture moment, make sure the duration specified matches with that of your PSP.
- Order type: Specify per order type whether this payment method should be active for it or not.
These OU settings are irrelevant when stores are operating in Local mode, and therefore ignored when Local mode is activated.
Custom Fields
The Custom fields tab will only be visible if the Payment method field specified in the General details was a Custom payment method.
Here you can add custom field(s) to custom payment methods. The user interface to configure ones is similar to the one found in the Custom Fields chapter. However, payment custom fields can only be added or edited here, and not from the Custom Fields chapter.
Settings
The Settings card allows you to edit or further fine-tune the use of a payment method even further. It consists of three cards: General details, Options, Organization unit settings, and the Custom fields tab.
Flexible Type Mapping Configuration
This setting allows for flexible payment type mapping once a transaction is completed using a specific payment method.
To map various cards under the "Card" payment type while differentiating between cards like MasterCard and external Gift Cards, set Pin:UseFlexibleTypeMapping to true.
Furthermore, for each card network supported by your PIN provider, create a distinct payment type. Make sure the code for each type matches the card circuit. The payment method for these types should be linked to your payment provider (e.g., Adyen). This configuration will update the payment type upon transaction completion.