Skip to main content

Payment methods

Background information payments

For more information on payments in general, as well as an explanation of integrated and non-integrated (custom) payment parties, see Payments under Concepts.

Authorization

In order to be able to access this chapter, you need the PaymentMethods and PaymentTypes permissions.

The Payment methods chapter in the Financials module gives you a clear overview of all different payment methods, such as Adyen, AdyenCheckoutAPI, EVAPay or Mollie, followed by the payment method's available payment types. In case of the AdyenCheckoutAPI for example, the payment types will be iDeal, Credit Card, PayPal, etc. Many payment methods will come preconfigured in your environment.

In the right pane you can see two types of filters, one specifically for the payment methods and the other for the payment types. Both filters offer more filter options relevant to its kind of filter.


By clicking an existing payment type, you can check its details and update them if necessary. Clicking Next lets you save any changes you made.

Creating a payment method

Using the + icon in the Payment methods overview itself (top right) lets you add a completely new custom payment method by entering a Name and Code. This code, when creating a new payment method, is not used in its configuration and is more indicative than anything else.

Adding a payment type

You can add a new payment type to a method by clicking the + icon in the table of a specific payment method. When you set the Code, be sure to specify it exactly as required by the PSP. You can read more about the format of these codes below this table, or go to Adyen payments for more background information.

The fields used in creation of a payment type and their descriptions are mapped in the following table.

FieldDescription
NameThe name of the payment method, specifically how it will be displayed
CodeThe internal reference code for system to system communication.
Note: it's important that this follows the format as specified by the PSP.
Backend IDBackendID of the payment type
Organization unitOU for which the payment type will be available.
Organization unit setOU set for which the payment type will be available.
Return methodDefine what action should be taken when an order is returned with payments on it.

Default ->
- Blocked -> the order can't be returned
- Forced -> automatically create refunds for these payments
Payment categoryPayment categories are set for compliancy reasons: they don't affect your payment directly, but this way you can designate the payments as one of the generic categories as used by the fiscal printers and in the audit files.

Other = 0
Debit = 1
Credit = 2
Cash = 3
Voucher = 4
Online = 5
Rounding = 6
ActiveEnable/disable the payment type.

Payment type Codes

The payment method dictates what should be entered in the Code field, since the code has to match the PSPs internal reference. If we'd use the ADYEN_CHECKOUT_API payment method for example, we need the following the code format as set by Adyen, which comes down to: ADYEN_CHECKOUT_API_BRANDNAME.

The 'BRANDNAME' here is the code used by Adyen for their own integration with another payment provider, such as iDeal. In case of iDEAL it would likely be ADYEN_CHECKOUT_API_IDEAL. But you can read more about the Adyen payments specifically in the Payments using Adyen docs.

Options

The Options card allows you to finetune the use of the payment method even further. This card differs for default and custom payment methods: custom payment methods will show you a more expansive card with more options. All fields contain a dropdown with options to choose from, with most options very straightforward.

Cash journal method

The Cash journal method benefits from a little more information: this field is used for payment types that have some physical representation. Mostly just cash. This defines when the cash journal for this payment type should be counted in the store, with the following variation possible:

  • 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

Options for regular payment methods


Options for loyalty payment methods

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.

Options for custom payment methods


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.

Right combination of options

Keep in mind that some of the 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 optionally add an organization unit set for which to set a Refund priority, Capture moment and Authorization expiration. The latter will only be enabled if the capture moment is set to anything else than None. After doing so, this payment type will also be displayed in the Payment settings chapter.


Refund priority
The Refund priority is set by entering any number - the higher the number, the higher the priority.

Capture moment
The Capture moment is a dropdown offering the following options:

  • None: direct capture moment (such as when using PIN in store)
  • Manual: manual action required (such as in the hotel example)
  • Ship: when the order is shipped
  • Confirmation: as soon as the order is confirmed

Order type
Specify per order type whether this payment method should be active for it or not.

Custom fields

It's possible to add custom fields to the custom payment methods. This custom field works in just the same way as every other custom field throughout Admin Suite.


Payment types visibility

See Custom payment methods in Integrations for services to fine-tune for whom a payment type should (not) be visible in the POS and Companion.