Technical update 2022-04

This update was sent in April 2022.

Release of remainder after doing a partial capture

The eCom API now supports both partial capture (as before) and release of the remainder of the reserved amount.

If you wish to cancel an order which you have partially captured: Send a PUT:/ecomm/v2/payments/{orderId}/cancel request with shouldReleaseRemainingFunds: true in the body. The payment must be RESERVED for this to take effect. See: Cancelling a partially captured order.

The QR API now works in the test environment

The QR API now works in both in the production and test environment.

Logo handling changes in PSP Signup API

The response of the GET:/v1/merchants/{merchantSerialNumber} endpoint in the PSP API contains a logo field, with the merchant's logo encoded in base64 format.

We are changing this to a URL, with a new field logoUrl in the response, pointing to a separate and highly available service where we will host the logo images.

The logo field in this API response is from now on deprecated, and will be removed on 30. May.

Please switch to the new logoUrl field as soon as possible.

This change only applies to the GET method, and does not affect the POST and PATCH methods.

Recurring charge changes

From August 1st, 2022 some new rules for charge creation will be enforced:

• The amount of a charge is flexible but cannot be higher than the agreement price.
• For an agreement with a campaign, the amount of a charge is flexible but cannot be higher than the campaign price. After the campaign expires the amount of a charge cannot be higher than the agreement price.

If the agreement was created with an initial charge and the initial charge amount is the same amount as the campaign price, then no new charges can be created until the next interval for the campaign.

See: Create charge.

Reminders

Please check your eCom API calls

We are working on eliminating incorrect API use. Although we always respond to incorrect API calls with a sensible HTTP status (usually HTTP 400 Bad Request) and an informative error message in the response body, we see that some merchant and partners keep making incorrect API calls.

Please:

• Monitor the responses you get when making API calls
• Log all errors
• Fix errors as quickly as possible
• Use the API Dashboard
• Contact us if there is anything we can help with

One example: Far too many calls to POST:/ecomm/v2/payments use an incorrectly formatted phone number. The effect is that the user's phone number is not correctly prefilled on the Vipps landing page. Please make sure you send the mobileNumber in 12345678 format, not +47 91 23 45 67 or something else. We have previously tried to respond with HTTP 400 Bad Request (as we should) for incorrectly formatted phone numbers, but that broke a lot of integrations, so we decided to accept the incorrect API calls even though they give a poor user experience.

See:

• FAQ: Common errors

Use the API Dashboard to find problems with your integration

UPDATE from 12 Jan 2024: The API Dashboard is deprecated.

The API Dashboard is available to all merchants for both the production and test environments, and is an easy way to see if you are using the APIs correctly. Think of it as a "health check", that you can use to see if there are any problems you need to investigate.

See it on portal.vipps.no in the Utvikler section. Here's an example for the eCom API's /refund endpoint:

How to get help quickly

Please see this page.

Technical updates archive

Please see: technical updates

Questions or comments?

We're always happy to help with code or other questions you might have! Please create GitHub issues or pull requests for the relevant API, or contact us.