Frequently asked questions

See the Recurring API for all the details.

For general information and questions, please check in the Knowledge base.

Core functionality

Does the user have to pay an initial charge?

No, this is up to the merchant. Vipps MobilePay always verifies the user's payment source, so even if there is no upfront payment we ensure that the user provides a valid payment source when entering the agreement. See: How Recurring Agreements works.

Does the user have to confirm each payment?

No. When a user has entered a payment agreement, the charges don't require any user action. Users may choose to be informed of payments, but there is no functionality for accepting or rejecting charges.

See: Are users notified of every charge?

Is there a delay for charges?

No. Charges are processed on the due date specified by the merchant, and payments are processed without delays.

We do require that charges are created at least two days in advance, so the user is able to see the upcoming charge. This does not mean that there is a delay, as the charge is processed on the due date. For special cases it's also possible to send charges one day in advance, and also to make unscheduled charges that are processed immediately.

When a charge is completed the merchant is immediately notified using the Webhooks API, the charge details can be retrieved, and the settlement data is also available in the Report API.

Unlike for normal card payments ("card on file") the Recurring API enables retries: If the first charge attempt (C) fails, for instance due to insufficient funds, the charge will be retried every day, for as long as the merchants specifies. Normal card payments would stop at step E if the charge attempt fails.

Vipps MobilePay will inform the user with push notification and in-app messages how to complete the payment, significantly increasing the success rate compared to normal card payments.

See:

• Charge retries
• Charge type
• Notifications to users for failed charges

Managing agreements in the app

Can users stop payment agreements in the Vipps MobilePay app?

Yes, sometimes.

1. All agreements must have a valid agreement URL, so users can easily access the merchant's website and manage the agreement. We strongly recommend using Vipps MobilePay Login for users accessing the agreement URL. If the agreement URL changes you must update the agreement.
2. Users can stop payment agreements directly in our app: Stopping an agreement in the Vipps MobilePay app.
3. KAM merchants (merchants with a Key Account Manager) can "opt out" of this: Opting out of the Stop Payment Agreement feature.

info

In extreme cases, where many users contact our customer service because they can't get help from the merchant to cancel their payment agreement, we may enable the "stop agreement" in our app. We may also do the same when an agreement has an agreement URL that does not take the user directly to the page where the agreement can be managed.

Are users notified of every charge?

Notifications for charge are not enabled by default, but users can choose to get notified of charges when they enter an agreement, and when they manage the agreement.

This is similar to how eFaktura works in Norway, Betalingsservice in Denmark and Finvoice in Finland.

We want users to be in control of their agreements, and notifications help users trust both Vipps MobilePay and the merchant, and not be "tricked" to pay without knowing.

Admin/partners

How do you change partners?

See Partner guide: How to change partners.

Important

On each agreement there is a merchantAgreementUrl which is the link each user clicks on to be able to change their subscription (e.g., a "My page" for the user). If the link structure is not the same in both solutions, you must update all existing agreements with a new URL as soon as possible after the move, so that the customers can manage the agreements further without coming to a blank page.

note

The Merchant Serial Number value (e.g., 281014) does not change when changing partners.

Migration

How do I migrate from the MobilePay subscription solution?

See: Migration guide.

Can I manage agreements and charges created with v2 API using v3 API?

Yes. All agreements and charges created with the v2 API can be retrieved and managed using the v3 API and vice-versa. Also, if an agreement was created with v2 API, it is possible to create a charge for this agreement with v3 API and vice-versa.

How can I move agreements between merchants and sales units?

Merchants sometimes need to move customer agreements from one merchant to another, or from one sales unit to another.

Clarification of terms:

• Merchant: A juridical unit, typically called a business or company, identified with organization number (also called, "org number" or "orgno").
• Sales unit: A merchant can have one or more sales units. It may be different brands, different physical locations, different services, etc.
• MSN: The unique ID of a sales unit. MSN is short for "Merchant Serial Number" which identifies a sales unit.

The following are the scenarios for moving agreements

• from one MSN to another, and both MSNs are under the same org number
• from one org number to another, and both org numbers are owned by the same parent org numbers
• from one org number to another, and the org numbers are not owned by a parent company (due to acquisition and mergers)

note

The general process is:

1. Log in on portal.vippsmobilepay.com and enter a new agreement with Vipps MobilePay for the new org number.

2. Order Recurring Payments.

3. Inform all of your existing customers about the change. If it's a new org number or there is a change of sales unit name, send us a confirmation that you have informed your end-users that the agreement is being transferred.

4. Email us at developer@vippsmobilepay.com (or use your Slack channel if you have one) and include all the following information:

   1. Merchant serial number you wish to migrate from
   2. Merchant serial number you wish to migrate to
   3. Copy of the letter/mail to users about the change to confirm that all customers have been informed as stated in point 3

5. The migration requests will be performed every Thursday between 9-11, except on public holidays. We must have received your request no later than Wednesday at 9 in order to be added to the following Thursday batch.

6. As part of the migration

   • All PENDING and DUE charges of agreements under 4.i will be cancelled
   • All agreements under 4.i will be stopped
   • Agreements identical to the old ones will be created under 4.ii with new agreement ID

7. After the migration, you will get a file that maps old agreement ID to the new agreement ID. This is a CSV where each line is an agreement, and the columns are old ID and new ID.

8. You then need to update your systems, so you start using the new agreement IDs to manage the agreement, perform new charges. We recommend keeping track of all agreements a customer has ever been associated with, so that you have the opportunity to retrieve previous agreements, charges, etc., if needed. Use the respective agreement ID and MSN in your API requests.

9. After the migration,

   • The new MSN 4.ii would not have the authority to capture/refund/etc. on old charges those were associated with 4.i. This means that, you need to use the old MSN 4.i and the old agreement ID in the API requests to perform the changes.
   • It will not be possible to make new charges on agreements under old MSN 4.i.
   • The user will still be able to see the old agreement in the app, under Stopped agreements and find the payment history up to the time of migration.
   • If the merchant deactivates an MSN that has active agreements, it will no longer be possible to perform any operations on the agreements and charges of that MSN.

Important

If a partner is managing your integration be sure to inform your partner about the migration and supply them with the new MSN 4.ii. Specifically request them to confirm step 8 and 9 above to ensure that they are prepared for the migration as well as the timeline. Be aware that we will not inform your partner about the migration, that is your responsibility to align with them.

Please note: The downtime experienced by end-users hinges on how effectively your systems manage the absence of agreement data from existing customers during migration. If your systems handle this transition smoothly, end-users may not encounter any downtime.

Common problems/errors

Why do I get the error merchant.not.allowed.for.recurring.operation?

The merchant.not.allowed.for.recurring.operation error indicates that the Recurring API is not yet activated for this sales unit.

The Recurring API is available for existing customers that have Payment Integration, a direct integration with the ePayment API or eCom API, and have completed some additional Know Your Customer (KYC) checks required by the financial authorities.

Vipps MobilePay is required to perform some extra compliance checks before activating the Recurring API.

Please order Recurring Payments to get access to the Recurring API in production.