skipLandingPage should support fallBack

[NinitoAS]

Hi,

I do not see any reason why skipLandingPage deprecates the fallback URL.

Vipps should include the fallback URL in the payment request in Vipps, instead of today's solution where the user gets stuck on the Vipps app payment accepted page if skipLandingPage is true.

Initiating payment through a serviced POS is not the only use case for the skipLandingPage (e.g. self-service kiosk), thus leaving a potential end-user stranded on the payment accepted page without being sent to the fallback URL, which makes paying with Vipps a worse user-experience

Obviously, the Vipps app supports sending users to external sites, after payment has been processed, when using the deeplink/isApp method of initiating the payment, so I do not see the reason why the fallback URL is not used inside the app as well

Maybe implement a new parameter for when initiating payments through the Vipps API: fallBackInApp (true/false --> Default false) which sends the customer to the fallback on the customer's phone after payment is done

Any thoughts on this?

[cloveras]

Hi @NinitoAS

The Vipps eCom API was originally designed for online shopping. It has evolved since that, with additions like skipLandingPage.

skipLandingPage is typically used when there is no customer-facing display.

The user should never be stranded. It is always possible to poll the status of a payment with GET:/ecomm/v2/payments/{orderId}/details.

Christian

[NinitoAS]

Hi Christian,

Thank you for your message. I believe I could be a bit more clear on the issue.

What we and many others would like to achieve here is the following flow:

1. Request a phone number while skip landing page where the payment is initiated from a POS for example
2. After the user pays, he is sent to our payment accepted page where he can download his receipt for example

The Vipps app should include a fallback URL when the user is requested to pay an order on Vipps by their phone number, and once they pay, the user should be sent to the fallback URL. The Vipps app already supports this logic if we use a deeplink to initiate the Vipps payment, so this would require small changes from the Vipps app to support such functionality

What we mean by "the user being stranded" is in fact that after the payment, the user is stuck in the Vipps app, which makes the user experience with Vipps much worse when the user pays through a POS or self-service kiosk rather than using a deeplink

Is the issue clear? We would be happy to jump on a call to explain all the problems this small functionality would fix. In addition, it would make it clear for the user, that no matter which platform (POS, self-service kiosk, webshop, app) they use, they will end up on the fallback URL

[cloveras]

Hi @NinitoAS

Thanks for the additional details.

We'll discuss this a bit, and will send an update ASAP.

Btw: Have you seen the Order Management API? You can send a receipt: https://github.com/vippsas/vipps-order-management-api

[cloveras]

In the meantime, here's a FAQ link: https://github.com/vippsas/vipps-ecom-api/blob/master/vipps-ecom-api.md#skip-landing-page

Please note: When using skipLandingPage, the user is not sent to a URL after completion of the payment. The "result page" is just the confirmation in Vipps. Therefore, the fallback URL sent in the API request can simply be the merchant's main URL.

[NinitoAS]

Hi, again Christian,

Thank you for following up and discussing this internally, we and many others really appreciate it. It would really benefit us.

Regarding the Order Management API, we have gone through it, but it's quite overkill for our restaurant customers, additionally, we already have a receipt functionality in our in-store solution, all we need is a proper redirect. This would also allow us and others to make changes on our side without needing additional development from Vipps

Thank you for the information though 😊

[matsjohans]

Hi,

You can have user redirected to a fallback page using our One-time-payment QR codes: https://vippsas.github.io/vipps-developer-docs/docs/APIs/qr-api/vipps-qr-one-time-payment-qpi-howitworks   In this case you initate a payment with SkipLandingPage=false, and generate a QR code to be presented on the customer faced display: https://vippsas.github.io/vipps-developer-docs/api/qr#tag/One-time-payment-QR

Regards Mats, Vipps

[NinitoAS]

Hey Mats,

Thanks for getting back to me. I understand that QR codes might seem like a great solution for making payments, but based on our research and testing, it's not as user-friendly as we all thought. Our customers have actually reported that QR codes can be intimidating and slow down the payment process. We gather data based on millions of monthly payments made through our solutions.

I know that Vipps has been promoting the use of QR codes recently, but in our market, it's not a popular way to pay yet. A lot of people don't even know that Vipps has this feature. If you take a look at your QR-code numbers, you'll see what I mean.

What we want to achieve is to make payments even easier, not the other way around. QR codes might be popular in other countries, but in our market, there are already so many ways to pay with Vipps (in-app, push, QR-code, Vipps store number, reoccurring payments, invoice payments, private payments, QR-code in bank terminal). I know you're trying to make it as easy as possible for customers, and so are we. That's why we won't be implementing a QR-code solution. It's much easier for customers to enter their phone number than to scan a QR-code inside the Vipps app, at least until it becomes more common, like in the Chinese markets.

Before we can fully rely on a QR-code payment solution, we hope that you can enable the functionality in the Vipps app, to send customers to the fallback URL, even though skipLandingPage is true and the customer gets a Vipps push. This is a simple change in the Vipps app and would not require much work, as it will just open a webpage based on the fallback URL during the payment initiation. So when Vipps gets a push notification, it should also include the fallback URL and after payment, it should send the user to the page chosen by the integrator.

Please don't take any offense to what I'm saying. I just wanted to share our experience in the payment industry with you.

Best Dexter

[cloveras]

Hello

You are of course free to choose if you want to use QR codes or not.

The eCom API will be (for some it already is) replaced by the ePayment API. Maybe that fits better with your needs? https://vippsas.github.io/vipps-developer-docs/docs/APIs/epayment-api

Christian

[cloveras]

FYI: The ePayment API will, at some point, replace the eCom API. We recommend to use the ePayment API. See: https://developer.vippsmobilepay.com/docs/APIs/epayment-api/

The new ePayment API is designed from scratch, based on everything we have learned through the eCom API over several years.

The main benefits are:

• Support for different flows, like pay by QR code, out-of-the-box without the "hacks" required in the eCom API
• Support for long-lived payments (payment requests from merchants) that are valid up to 28 days
• Support for free-standing card payments: Pay with VISA and MasterCard without the Vipps app
• Uses the Webhooks API to always reliably send information back to the merchant or partner

The ePayment API allows merchants to accept payments using the following payment methods:

• Vipps (the app)
• Credit and debit cards without Vipps. Please note: Card payment is not available in test environment.

[cloveras]

Closing this issue now.