Changelog

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

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 receipt 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

  • Make interval a non required field anymore in the POST:/recurring/v3/agreements request body. If not specified, the agreement will have a FLEXIBLE interval type.
  • Make it possible to update the type of an agreement interval. Update of [PATCH:/recurring/v3/agreements/{agreementId}][patch-agreement-endpoint] endpoint.

January 2024

• Added webhook integration documentation. See Webhooks and Webhooks API.

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 to update 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

• New optional field externalId for agreements introduced. This field can be used to store an external ID for the agreement. Can be set in the request body of the POST:/recurring/v3/agreements request. externalId will be returned by the GET:/recurring/v3/agreements/{agreementId} endpoint. It is also possible to update it using the PATCH:/recurring/v3/agreements/{agreementId} endpoint.

• New optional field countryCode for agreements introduced. Can be set in the request body of the POST:/recurring/v3/agreements request. countryCode will also be returned by the GET:/recurring/v3/agreements/{agreementId} endpoint.

• New field uuid (UUID representation of agreement ID) returned by the GET:/recurring/v3/agreements/{agreementId} response.

• New optional field externalId for charges introduced. This field can be used to store an external ID for the charge. Can be set in the POST:/recurring/v3/agreements/{agreementId}/charges request.

March 2023

• The new endpoint GET:/recurring/v3/charges/{chargeId} makes it possible to retrieve a charge specified by chargeId, without knowing the agreementId (unlike GET:/recurring/v3/agreements/{agreementId}/charges/{chargeId}). The resulting charge now contains the agreementId. Its purpose is to simplify investigations when the merchant lost track of which charge belongs to which agreement.

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 1 November 2023.