Payment methods
For more information on payments in general, as well as an explanation of integrated and non-integrated (custom) payment parties, see Payments under Concepts.
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.
| Field | Description |
|---|---|
| Name | The name of the payment method, specifically how it will be displayed |
| Code | The internal reference code for system to system communication. Note: it's important that this follows the format as specified by the PSP. |
| Backend ID | BackendID of the payment type |
| Organization unit | OU for which the payment type will be available. |
| Organization unit set | OU set for which the payment type will be available. |
| Return method | Define 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 category | Payment 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 |
| Active | Enable/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.
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
.png)
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 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.