Ctrlk
RegisterLogin

MobilePay

Checkout can be used to accept MobilePay payments.

Integration options supported: Hosted payment page (HPP) or IFRAME.

This guide requires familiarity with Accepting payments.

Integrate MobilePay via Checkout

Parameters
Type
Description

currency_code

String (required)

Supported currencies: EUR, NOK, SEK, DKK

amount

Integer (required)

Transaction amount

payment_contract_id

String (required)

Payment Provider Contract ID obtained from Verifone Central interface

customer

String (required)

Required only if threed_secure contract is applied and the transaction needs 3DS validation

app_phone_number

String (optional)

Phone number of the shopper. Max 18 characters.

dynamic_descriptor

String (optional)

Short text to be displayed on the bank statement of the cardholder. Support varies per Payment Contract (<= 25 characters)

capture_now

Boolean (optional)

Used for separate authorization and capture

card

Object (optional)

Payment configuration needed in case of 3DS or Authorization type

Authorization and capture

MobilePay transactions through the Checkout can be used to do a sale (capture_now = true) or to authorize without capturing immediately (capture_now = false). An authorized payment reserves the money and allows you to capture the funds at a later stage.

Sending a checkout request using MobilePay payment method:

{
    "currency_code": "EUR",
    "entity_id": "87db5a22-9e9e-4b71-9c61-6fb4f6628833",
    "customer": "4b32a5ef-dd84-45ba-81ae-f676ef032580",
    "configurations": {
        "mobile_pay": {
            "dynamic_descriptor": "Demo Description",
            "capture_now": false,
            "payment_contract_id": "e0a66743-fae4-4e59-a052-81f4729be299",
            "card": {
                "sca_compliance_level": "WALLET",
                "authorization_type": "FINAL_AUTH",
                "threed_secure": {
                    "enabled": true,
                    "threeds_contract_id": "86611b72-a870-428a-b436-8bee474e7132",
                    "total_items": "01",
                    "transaction_mode": "S"
                }
            }
        }
    },
    "amount": 850,
    "merchant_reference": "TEST 123",
    "return_url": "https://test.url.com",
    "interaction_type": "HPP"
}

Special conditions during purchase experience

  • The user initiates the purchase in a browser that is not the default one on their phone.

If a user initiates the purchase in a browser that is not the default one on their phone, and then they switch to MobilePay and accept the payment, the app will redirect to the merchant's URL which will always open in the default browser, even if it is not the same browser where the payment was initiated.

The MobilePay app cannot decide which browser is used, or redirect back to the first browser if that is not the default one.

In this case, as a merchant, you cannot rely on session objects and only rely on the data in the Redirect to show a confirmation page.

  • The user breaks the flow and does not return at all by closing the browser.

The user initiates the purchase and switches to MobilePay to accept the payment. Before the switch to merchant URL, the user closes MobilePay and/or browser.

The payment is successful and as a merchant you should complete the order based on the information from callbacks.

Handling responses

Whenever a card payment is processed via the Checkout, the responses events would contain additional fields specific to card payments in the details object.

Example of successful checkout via the Checkout:

Intercard integration will be available starting with 2023.

  • To ensure that the redirection request was not tampered with, always check that the transaction_id received as query parameter in the redirection matches the transaction_id property of the retrieved Checkout. If those are not matching, this is indication of either an incorrect integration, that the redirection to your return_url did not originate from Verifone, or transaction_id was tampered with.

  • You can now store the transaction_id value together with the order 1234 in your system to link the two together.

Scenarios

The table below describes the different outcomes of a Checkout. A full list error codes are available.

Description
Result
Merchant action

Failed transaction*

Redirect: checkout_id={checkout_id} & transaction_id={transaction_id} & errorCode=123

Unsuccessful payment (technical reason), do not display order confirmation

Successful transaction

Redirect: checkout_id={checkout_id} & transaction_id={transaction_id}

Display order confirmation

Customer visits the URL of an already completed Checkout

Redirect: checkout_id={checkout_id} & errorCode=168

Display corresponding message to the customer. Checkout is completed whenever there was a single successful payment processed through it.

Customer visits the URL of an expired Checkout

Redirect: checkout_id={checkout_id} & errorCode=169

Display corresponding message to the customer. Checkout is expired whenever the expiry_time is reached.

Customer visits the URL of a Checkout which has reached the maximum of failed payment attempts

Redirect: checkout_id={checkout_id} & errorCode=165

Display corresponding message to the customer. Payments through a single Checkout can be attempted up to three times unsuccessfully.

Form validation errors / Other service failures on the Checkout page

Displays error alert to Customer on the page

Customer is prompted to correct their form input and retry the payment or try using an alternate card or payment method

*Failed transaction - Depending on which step in the payment process failed, the transaction_id might not always be present as the query parameter.

PreviousKlarnaNextSwish

Last updated

Was this helpful?