Skip to main content

Choosing the right QR type

View as Markdown (opens in a new tab)
Install AI tools

Give your assistant up-to-date guidance for our APIs, with our plugin or without it.

The plugin is still under development. See the AI tools page for details.

Run both commands, in order.

claude plugin marketplace add vippsas/agent-toolkit
claude plugin install vipps-developer@agent-toolkit

For troubleshooting, see the full instructions.

Pick the QR type that matches the hardware at your checkout:

Your checkout hasUse
A QR scannerPersonal QR
A customer-facing screenOne-time payment QR
Neither, and you want to send customers to your websiteMerchant redirect QR
Neither, and you want to send a payment request when scannedMerchant callback QR

For what each QR type is and how it looks to the customer, see QR codes.

Payment flows involving QR codes​

Different solutions for different setups​

Depending on the merchant setup, there can be multiple ways to implement the payment flow. This section tries to sketch an overview of what is possible, and what might be the best approach depending on the merchant setup today.

A QR code identifies the customer or the checkout; the payment itself is made by a payment API. The flows differ mainly in how the customer is paired with the checkout that issues the payment.

Two of these flows are built into the ePayment API and need no call to the QR API at all: one-time payment QR and personal QR.

The next sections will contain the recommended approaches based on what capabilities the merchant has available at their checkouts.

Note

The developer documentation in Vipps MobilePay describes using webhooks instead of polling for payment statuses in the ePayment API. Polling, however, is still possible and a valid way to follow the payment status.

Checkout has QR scanning capabilities​

This is our recommended flow. If the merchant has the possibility to scan a QR code at their checkouts, they can use the 'Merchant Scan' approach. Before the payment is initiated, the merchant scans a QR on the customer's phone, which will contain the customer info needed to initiate the payment. The payment is then initiated with the userFlow parameter set to "PUSH_MESSAGE" together with the personalQr parameter set to the URL read from the QR code, unchanged. See the In-person payments example.

How to build it:

  1. Scan the QR code in the customer's app.
  2. Create the payment with the ePayment API, with userFlow: "PUSH_MESSAGE" and customer.personalQr set to the scanned URL, unchanged.
  3. Get the payment status with webhooks or polling.

See implementation details →

Checkout has customer facing screens​

In this scenario, there is one solution simpler than all others. Here, the merchant doesn't need the customer information before they initiate the payment. They simply initiate the payment where the userFlow parameter is set to QR. Then, the response will contain a link to a dynamic QR code, which the checkout then downloads and shows on their customer-facing screen. The user scans the QR and completes the payment flow. This flow is described in more detail in the ePayment API guide, where it also is shown how to specify the image format and size of the QR being created.

How to build it:

  1. Create the payment with the ePayment API, with userFlow: "QR".
  2. Show the returned QR image on your screen.
  3. Get the payment status with webhooks or polling.

See implementation details →

Checkout neither has QR scanners nor customer facing screens​

In these scenarios, the PoS merchants must use static QR codes as stickers. These QRs can work in two different ways.

The first option is where the QR code contains a link to a merchant website where the merchant will then ask for the customer info needed. This QR is referred to as a Merchant Redirect QR. See the QR to site (payment only) example.

How to build it:

See implementation details → To try it with curl or an API client first, see the Quick start.

The second option is called Merchant Callback QRs. When the QR is scanned by a customer, Vipps MobilePay will send a callback to an endpoint that is hosted by the merchant. The callback will contain a customerToken that is used to initiate the payment towards the customer. See the In-store using Merchant Callback QR example.

How to build it:

  1. Generate the QR code with PUT:/qr/v1/merchant-callback/{merchantQrId}.
  2. Subscribe to the user.checked-in.v1 webhook event to receive scan notifications.
  3. When the code is scanned, create the payment with the customerToken from the callback.

See implementation details →

Last updated on