Skip to main content

Changelog

All notable changes to the current API will be documented here. See: API lifecycle.

Changes that affect multiple APIs are documented in the general changelog.

October 2025​

  • Changed the default lead time for recurring charge creation from 2 days to 1 day. This update provides greater flexibility and enables merchants and partners to request payments until midnight before the due date. See: Recurring charges and Recurring API guide - Due date.

  • Added support for specifying that certain payment sources should be blocked when drafting new agreements. See: Draft agreement

    • Specifying which payment sources should be blocked is done through the new paymentMethod object property. E.g. if you want to block commercial cards, you would add the following to the draft agreement request body:
      paymentMethod: {
        blockedSources: ["COMMERCIAL_CARDS"]
      }
    • Please note that only commercial cards are supported for now, meaning that this is the only payment source that can be blocked for any given agreement.
    • Please also note that this functionality is only supported for new agreements—it's not possible to update existing agreements to add or remove blocked payment sources.

September 2025​

  • Updated the rate limit for the charge creation endpoint. Instead of having separate limits for RECURRING (500/minute) and UNSCHEDULED (300/minute), there is now a single limit of 500 requests per minute. See: Rate limits
  • Added Not Acceptable to list of problem types. See Recurring API problem types.

August 2025​

  • Enabled refunds of recurring transactions on portal.vippsmobilepay.com for merchants in Denmark and Finland.
    • Previously, if you performed a manual refund on the portal, the API could return outdated charge details until you repeated the same refund operation via the API.
    • From 19 August 2025, the API returns updated information immediately, including any refund operations performed in the portal, and a webhook event is sent.

July 2025​

  • Removed deprecated countryCode field from create agreement request schema. See: Create agreement
    • Existing integrations that include countryCode as part of the request body when creating new agreements, will continue to work as usual. The field will simply be ignored when parsing the request.
  • Updated sections of the documentation following the launch of new designs for payment agreement sign up flow in Android version > 8.23.0 and iOS version > 8.25.0.

June 2025​

  • Adjusted auto-fail logic for recurring SINGLE_ATTEMPT charges. See Processing mode.
    • SINGLE_ATTEMPT charges that are not able to be successfully processed, will now be auto-failed after initial processing time on due date + 2 hours—instead of end of day on due date + 2 hours.
    • E.g. if the charge is picked up for processing as part of a charge batch that runs 2025-06-12T00:03:00Z, it will be auto-failed sometime after 2025-06-12T00:05:00Z, depending on processing time in the batch.
  • Updated request body validation for Create Charge endpoints
    • Increased character limit on the orderId field from 50 to 64.

May 2025​

  • Adjusted serialization logic for agreement webhook payloads, so null values are now omitted. See: Agreement webhook event payloads
    • This change mainly affects the actor field, which used to be included with a default value of null for all agreement webhook event payloads except the recurring.agreement-stopped.v1 event (which has a non-null value that indicates who stopped the agreement).
    • Only recurring.agreement-stopped.v1 webhook event payloads will now contain the actor field.
  • Standardized format of ISO 8601 UTC timestamp included in the occurred field for all webhook event payloads. See: Agreement webhook event payloads and Charge webhook event payloads
    • The format of ISO dates can vary, having optional seconds and fractional seconds. We have standardized the format of the timestamp in this field to always include seconds and fractional seconds with 7 decimal precision, e.g. 2025-05-02T10:36:43.4880000Z.

April 2025​

  • Updated failure codes and explanations for charge webhook payloads. See: Charge webhook event payloads
  • Added new charge webhook event type: recurring.charge-refunded.v1. See: Webhooks

February 2025​

  • Removed references to V2 API

January 2025​

  • Webhook improvements:

    We have introduced failureReason to charge webhook payloads. This field will match the failureReason supplied in the API response for failing charges. We also added deprecation notice to failureText field, which has been replaced by failureReason

  • Flexible Pricing representation for agreements: Flexible pricing agreements are supported for Norway.

  • We have introduced an optional parameter processingMode for charges, that could be set to modify the retry behaviour of a charge. Both new and existing charges will contain this parameter when fetched/listed. See Processing mode.

December 2024​

  • Webhook improvements: We have stopped sending failureCode, failureText and chargeExternalId from charge webhook payloads if they were null.

November 2024​

September 2024​

  • List agreements v3 endpoint now supports pagination using the pageNumber and pageSize query parameters. See List Agreements endpoint We recommend that you use the pageNumber and pageSize query to paginate the response. If not used, it could result in increased response times when the number of agreements is more. The chances of causing instabilities to other endpoints cannot be ruled out either. Also, the API endpoint allows merchants to fetch all agreements. If no query status is supplied, it will default to only retrieving the active agreements. There is no way to list all agreements with all statuses, due to performance.

July 2024​

  • phoneNumber is validated only if skipLandingPage is set to true If phoneNumber is invalid and skipLandingPage is set to false, the Recurring API ignores the value and the user will have to enter their phone number on the landing page. If phoneNumber is invalid and skipLandingPage is set to true, the Recurring API will return the following error:

    {
     "type": "https://developer.vippsmobilepay.com/docs/APIs/recurring-api/vipps-recurring-api-problems#validation-error",
     "title": "Bad Request",
     "status": 400,
     "detail": "Invalid phone number",
     "instance": "/vipps-recurring-merchant-api/v3/agreements",
     "contextId": "8d728430-e5f1-4d76-a045-6a57231618b4"
    }

  • merchantRedirectUrl max length was increased to 2048. See: DraftAgreementV3 definition:

  • Updated Payment Batches Schedule for Danish and Finnish market. The new timings are to avoid the batches running during the scheduled maintenance windows of Vipps MobilePay's vendors/partner banks. See: Payment Batches Schedule:.

May 2024​

April 2024​

  • Fixed issue that caused some webhooks/callbacks to be sent before amounts were updated, which caused incorrect information in webhooks/callbacks. There is no plan for resending these webhooks/callbacks as of now, please reach out if this has caused any issues.

Mars 2024​

  • If externalId is specified on the charge, it will be visible to the user on the charge order details screen.

February 2024​

  • Added new webhook event type recurring.charge-creation-failed.v1. See: Webhooks.

  • Added documentation for charge batch creation endpoint. See: Create multiple charges.

  • Unscheduled charge release. Please note that for MobilePay re-integrating merchants, this is the equivalent of the one-off auto-reserve feature. See: Unscheduled charge.

  • Flexible interval

January 2024​

December 2023​

  • Fixed released to return extraDetails in error response body format according to the RFC. See: Errors.

November 2023​

  • Landing page update. Due to complexity of which price applies to an agreement, whether it's the agreement price, initial charge price, promotional price, etc., the landing page will show agreement names instead of prices.

  • Charge externalId:

    • If specified, the externalId will be used as order ID, meaning it will show up on settlement reports in place of the orderId field.
    • If both orderId and externalId are specified, the externalId will be used as order ID, while orderId will just be used to identify the charge in the Recurring API.

October 2023​

  • Fixes in the Recurring OpenAPI spec file:

    • The optional field externalId can be set on an initial charge in the request body of the POST:/recurring/v3/agreements request.
    • createdAfter query parameter on the GET:/recurring/v3/agreements is of type int64.
    • failureReason field returned in the ChargeResponseV3 can be null.
    • chargeId field in the DraftAgreementResponseV3 can be null.
    • campaign field in the AgreementResponseV3 can be null.
    • PricingResponse can either be of type VariableAmountPricingResponse or LegacyPricingResponse.

  • New optional field interval in the PATCH:/recurring/v3/agreements/{agreementId} endpoint, which allows updating the interval of an active agreement.

August 2023​

  • Removed charge-amount-too-high-for-interval validation used in charge creation endpoint POST:/recurring/v3/agreements/{agreementId}/charges. The suggestedMaxAmount field for a variable amount agreement should be set to what the maximum amount could be for each charge.

June 2023​

  • A new field is returned by the GET:/recurring/v3/agreements/{agreementId} endpoint:
    • vippsConfirmationUrl: previously redirected the user to the landing page in a desktop flow (with https://), or to the Vipps or MobilePay app in a mobile flow (with vipps://), where the user can then approve the agreement.

May 2023​

  • New fields returned by the GET:/recurring/v3/agreements/{agreementId} endpoint:

    • merchantAgreementUrl: URL where Vipps can send the customer to view/manage their subscription.
    • merchantRedirectUrl: URL where customer should be redirected after the agreement has been approved/rejected in the Vipps mobile application.
    • created: Date when agreement was created in ISO 8601 format.

  • New fields returned by the GET:/recurring/v3/agreements/{agreementId}/charges/{chargeId} endpoint:

    • retryDays: The service will attempt to charge the customer for the number of days specified in retryDays after the due date.
    • externalAgreementId: Can be used by the merchant to map the agreementId to an ID in a subscription system or similar.

April 2023​

March 2023​

December 2022​

  • Version 3 is available and includes new and improved functionality for campaigns, the ability to reserve and capture charges, and several technical improvements. The migration guide and quick start provide more details for upgrading to v3. Version 2 will be phased out and will no longer be available from 2023-11-01.
Last updated on