You can start a hostedCheckout flow by posting the relevant details to the endpoint. We will then return you all the details you need to redirect the consumer to us, retrieve the status and recognize the consumer when he/she returns to your website. The hosted checkout allows the use of three distinct components:

• Presenting a (filtered) list of payment products that the consumer can choose from;

• Handling of the actual payment, potentially involving data capture, redirection and/or the displaying of payment instructions;

• Presenting a confirmation/failure page after the payment.

Step 1 and 3 from the above list are optional. When no or partial filtering is provided, the first page the consumer will see is a payment product selection page. However, the hosted checkout will start as if a payment product had been selected if that specific payment product is the only entry in the request's restriction filters.

By providing payment product ids and groups in the hostedCheckoutSpecificInput's paymentProductFilters object, you can reduce the list of available payment products by either excluding or restricting to certain products. Note that at least one viable payment product must be left after filtering and that exclusion is leading, meaning that restricting and excluding the same product will lead to exclusion.

By setting the tokensOnly boolean to true, as part of the paymentProductFilters object, the consumer may only complete the payment using one of the accounts on file provided in the tokens property of hostedCheckoutSpecificInput.

By setting the showResultPage boolean to false, as part of the hostedCheckoutSpecificInput, the system will skip the confirmation/failure page after the consumer has completed the payment. This setting is true by default and the results page will be presented to the user.

In case the payment product selection page needs to be skipped the hostedCheckout call needs to contain one of the following objects in which all payment products have been categorized. These will also be used if the consumer selects a related payment product.

• Card payments - cardPaymentMethodSpecificInput

• All credit and debit card products fall into this category if they allow for direct submission of card data without a redirect to a third party to capture the card details.

• Redirect payments - redirectPaymentMethodSpecificInput

• Mobile payments - mobilePaymentMethodSpecificInput

• All payment products that involve a redirect to a third party to complete the payment directly online, like PayPal.

A generic transaction can be submitted using the order and the fraudFields objects.