> **Description:** Integration checklist for PSPs implementing card passthrough with the Recurring API.

# Recurring PSP API checklist

**Coming soon**

This checklist is under development.

Use this checklist to ensure your Recurring PSP API implementation is complete and production-ready.
It covers the key endpoints, quality assurance steps and pitfalls -- from payments to captures, refunds, and error handling.

## Flow to go live

1. Complete your testing of the Recurring PSP API. Use the list below to ensure you cover all areas of the integration before you submit the checklist.

2. Send your filled out checklist to us at [developer@vippsmobilepay.com](mailto:developer@vippsmobilepay.com).
Request examples in the checklist must be no more than 1 month old at the time you submit the checklist.
Together with the checklist, please include a short description of your solution.

3. We will verify your integration and get back to you as soon as possible.
After the checklist is approved, we'll send you the information you need to go live.

### Endpoints to integrate

Integrate the following [Recurring API endpoints](https://developer.vippsmobilepay.com/redocusaurus/recurring-swagger-id.yaml).

For examples of requests and responses, see the [Recurring API quick start guide](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-quick-start.md).

| Purpose | Endpoint |
| --- | --- |
| Agreement: Create an agreement | POST /recurring/v3/agreements |
| Agreement: Retrieve an agreement | GET /recurring/v3/agreements/{'{agreementId}'} |
| Agreement: Update an agreement | PATCH /recurring/v3/agreements/{'{agreementId}'} |
| Agreement: List charges | GET /recurring/v3/agreements/{'{agreementId}'}/charges |
| Charge: Create charges (batch) | POST /recurring/v4/agreements/charges |
| Charge: Get payment info | GET /recurring/v4/agreements/{'{agreementId}'}/charges/{'{chargeId}'}/payment-info |
| Charge: Report a charge result | POST /recurring/v4/agreements/{'{agreementId}'}/charges/{'{chargeId}'}/result |
| Charge: Retrieve a charge | GET /recurring/v3/agreements/{'{agreementId}'}/charges/{'{chargeId}'} |
| Charge: Cancel a charge | DELETE /recurring/v3/agreements/{'{agreementId}'}/charges/{'{chargeId}'} |
| Charge: Refund a charge | POST /recurring/v3/agreements/{'{agreementId}'}/charges/{'{chargeId}'}/refund |
| Charge: Capture a reserved charge | POST /recurring/v3/agreements/{'{agreementId}'}/charges/{'{chargeId}'}/capture |

### Quality assurance

Ensure that your implementation complies with our requirements and recommendations.

| #### Handle errors Monitor the error messages Vipps MobilePay returns from the APIs and correct problems as quickly as possible. It's recommended to log errors emitted by our APIs. This makes it easier to pinpoint what has gone wrong. If you're new to handling errors, see [HTTP Responses](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#http-responses). |
| --- |
| #### Include standard HTTP headers Send the [HTTP headers](https://developer.vippsmobilepay.com/docs/knowledge-base/http-headers.md) in all API requests for better tracking and troubleshooting (mandatory for partners and platforms, who must send these headers as part of the checklist approval). |

### Avoid integration pitfalls

Avoid these common mistakes to ensure the best user experience.

| #### Track status with webhooks and polling The merchant *must not* rely on `Redirect` alone, but must always poll [`GET:/recurring/v3/agreements/{agreementId}`][fetch-agreement-endpoint] to check the status of the agreement. However, to minimize [polling](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#polling-guidelines), you must also implement the [Webhooks API](https://developer.vippsmobilepay.com/docs/APIs/webhooks-api/events.md#recurring-api-event-types) to receive real-time updates on agreement or charge status changes. Polling can be used as a fallback for verification. |
| --- |
| #### Provide subscription tools The merchant must have a way for the user to manage and stop their subscription in `merchantAgreementUrl` in their agreement. This should result in a timely update of the Vipps MobilePay agreement. |
| #### Follow design guidelines The Vipps MobilePay branding must be according to the [design guidelines](https://developer.vippsmobilepay.com/docs/knowledge-base/design-guidelines.md). |
| #### Educate customer support Make sure your customer support has all the tools and information they need available in *your* system, through the APIs listed in the first item in this checklist, and that they do not need to visit the [business portal](https://portal.vippsmobilepay.com) for normal work. |
| #### Use at least two `retryDays` The success rate of charges increases significantly when `retryDays` is set to two or more. |
| #### Monitor agreement and charge statuses Merchants must listen to [Webhooks](https://developer.vippsmobilepay.com/docs/APIs/webhooks-api/events.md#recurring-api-event-types) to track critical events such as: - Agreement cancellations - Activation of agreements - Charge-related updates (e.g., successful or failed charges) This ensures merchants do not request payments on canceled agreements and avoid errors caused by outdated agreement statuses. Webhooks provide real-time updates. Use polling as a fallback mechanism to verify agreement and payment statuses if webhook delivery fails. |

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