> **Description:** Details about API and platform updates for February 2025, including new features, improvements, and important changes to Vipps services.

# Technical update Feb 2025

This update was sent in February 2025.

## Partner portal

The partner portal
is live, enabling partners and large merchants (that are configured as partners) to:

* Check the status of all product orders
* Get the details for one merchant
* Get a list of all sales units
* Get a list of all sales units for one merchant
* Get details for a sales unit
* Get a list of price packages

It is a Minimum Viable Product (MVP), and we would like input on what to prioritize.
See [About the partner portal](https://developer.vippsmobilepay.com/docs/partner/partner-portal.md) for more details.

## ePayment API: Error codes

The error response from the
[ePayment API](https://developer.vippsmobilepay.com/docs/APIs/epayment-api/README.md)
now includes a
[four digit error code](https://developer.vippsmobilepay.com/docs/APIs/epayment-api/api-guide/errors.md),
making it easier to map it to error messages for end users.

## Recurring API updates

### Reminder about changes to List Agreements endpoint

**Reminder**

This is a repetition from the
[2024-11 technical update](https://developer.vippsmobilepay.com/docs/technical-updates/2024-11.md).

We observe that many integrations don't use the recommended way of using the `pageNumber` and `pageSize` filters while calling the
[List Agreements endpoint](https://developer.vippsmobilepay.com/redocusaurus/recurring-swagger-id.yaml).
This will result in increased response times when the number of agreements is high, and high loads on the server side.

Because of this, we will enforce the default values 2025-02-01:
*`pageNumber`: 1 and `pageSize`: 500.

### Recurring API V2 is discontinued

As announced in the [2024-11 technical update](https://developer.vippsmobilepay.com/docs/technical-updates/2024-11.md),
the Recurring API version 2 has been discontinued. Please migrate to version 3.
See the [Recurring API FAQ - Migration](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-faq.md#migration) section.

### Rate limit

To enhance the stability and security of our APIs, we will introduce new
[rate limits](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#rate-limiting)
starting from 2025-05-05.
This change will result in a `HTTP 429 Too Many Requests` response when this rate limit is exceeded.

| API         | Limit       | Key used    | Explanation |
| ----------- | ----------- | ----------- | ----------- |
| Create a new charge `type: RECURRING`    | 500       | `MerchantSerialNumber` | 500 calls per minute per MSN |
| Create a new charge `type: UNSCHEDULED`     | 300       | `MerchantSerialNumber` | 300 calls per minute per MSN |

This is to increase the stability and security of our API, and prevent incorrect API use.
The limits should not affect normal behavior.
We encourage merchants to adjust their charge creation logic to distribute requests evenly, minimizing the impact of rate limits.

### Pricing representation - Flexible Pricing

Previously only  Danish and  Finnish merchants were able to use flexible pricing representations
while creating new agreements.
Not anymore.
This feature is now available for Norway as well. More details can be found in
[Flexible pricing](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#flexible-pricing).

### Charge processing mode

We have introduced [charge processing mode](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#processing-mode)
for charges of type `RECURRING`.
This offers flexibility for merchants and partners who need to set that a recurring charge can be processed only once.

### `failureReason` as part of webhook events

We now return the `failureReason` in the `recurring.charge-failed.v1` and `recurring.charge-creation-failed.v1`
[webhook event types](https://developer.vippsmobilepay.com/docs/APIs/webhooks-api/events.md#charge-webhook-event-types).
The `failureReason` will enable merchants to advise their users to fix the issue with their payment agreement.

### Customer support cases for stopping agreements

Users often contact Vipps MobilePay customer support to get help to stop their payment agreements
because they are unable to stop the agreements in the merchant's website/app, or are unable to reach the merchant's customer support.
This is sometimes caused by an invalid `merchantAgreementUrl`, so users can not get to the merchant's website.

When Vipps MobilePay customer support stops these agreements, we will send a `recurring.agreement-stopped.v1`
webhook event where the actor parameter in the event payload will be `ADMIN`.

As communicated in the
[Recurring API guide: Opting out of the Stop Payment Agreement feature](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#opting-out-of-the-stop-payment-agreement-feature),
if we receive numerous calls from users wanting to terminate their agreements due to difficulties using the merchant's
"My Page" and unhelpful customer service from the merchant, we will take them off the opt-out list.

## MobilePay Subscriptions and App Payments: Reminder to get ready for facade migration

For the merchants and partners using the existing MobilePay Subscriptions and App payments, the deadline is approaching
where you need to migrate to the Recurring and ePayment API. We have improved and are expanding the migration
guides to assist you in the migrations.

## Questions or comments?

We're always happy to help with code or other questions you might have!
Please
[contact us](https://developer.vippsmobilepay.com/docs/contact.md).

> **Full site overview:** For every page in this documentation, read [https://developer.vippsmobilepay.com/llms.txt](https://developer.vippsmobilepay.com/llms.txt).
