Vipps Recurring Payments

The API call allows merchant to fetch all agreements. If no query status is supplied it will default to only retrieving active agreements. There is no way to list all Agreements with all statuses, this is due to performance. Use the createdAfter query to paginate the response. Mocked via Mockzilla.

The API call allows merchants to create agreements for a user to accept. Once the agreement is drafted you will receive a vippsConfirmationUrl. This is used to redirect the user to the landing page, or to the app if "isApp":true is used. If the user accepts or rejects the agreement, the user will be redirected back to whichever URL has been passed in merchantRedirectUrl. You have to implement polling on the agreement to check when the status changes to active instead of relying on the redirect back to the merchantRedirectUrl. We have no control over if a user is actually redirected back or not, this depends on what browser the user came from. Please note the different use cases for initialCharge and campaign. And when to use RESERVE_CAPTURE instead of DIRECT_CAPTURE as transactionType. More information about this can be found in the API documentation.

Fetch a single agreement for a user. Recommended to use when polling for status changes after sending an agreement to a user.

Updates the agreement. Note that when updating the status to STOPPED, you can not re-activate it. If you want to pause an agreement, we suggest leaving the agreement active and skipping the creation of charges as long as the agreement is paused in your systems.

Updates the agreement. Note that when updating the status to STOPPED, you can not re-activate it. If you want to pause an agreement, we suggest leaving the agreement active and skipping the creation of charges as long as the agreement is paused in your systems.

Forces an agreement to be accepted by the given customer phone number. This endpoint can only be used in the test environment. Available as a Mockzilla mock endpoint.

The API call allows merchant to fetch all agreements. If no query status is supplied it will default to only retrieving active agreements. There is no way to list all Agreements with all statuses, this is due to performance. Use the createdAfter query to paginate the response.

The API call allows merchants to create agreements for a user to accept. Once the agreement is drafted you will receive a vippsConfirmationUrl. This is used to redirect the user to the Vipps MobilePay landing page, or to the Vipps MobilePay app if "isApp":true is used. If the user accepts or rejects the agreement, the user will be redirected back to whichever URL has been passed in merchantRedirectUrl. You have to implement polling on the agreement to check when the status changes to active instead of relying on the redirect back to the merchantRedirectUrl. We have no control over if a user is actually redirected back or not, this depends on what browser the user came from. Please note the different use cases for initialCharge and campaign. And when to use RESERVE_CAPTURE instead of DIRECT_CAPTURE as transactionType. More information about this can be found in the API documentation.

Fetch a single agreement for a user. Recommended to use when polling for status changes after sending an agreement to a user.

Updates the agreement. Note that when updating the status to STOPPED, you can not re-activate it. If you want to pause an agreement, we suggest leaving the agreement active and skipping the creation of charges as long as the agreement is paused in your systems.

Forces an agreement to be accepted by the given customer phone number. This endpoint can only be used in the test environment. Mockzilla mock: no signup, no API key.

Fetches all charges for a single agreement, including the optional initial charge. Supports filtering on status using query parameter.

Creates a new recurring charge (payment) that will charge the user on the date specified. If the payment fails, the charge will be retried based on retryDays.

Fetch a single charge for a user.

Cancels a pending, due or reserved charge. When cancelling a charge that is PARTIALLY_CAPTURED, the remaining funds on the charge will be released back to the customer. Note if you cancel an agreement, there is no need to cancel the charges that belongs to the agreement. This will be done automatically.

Captures a reserved charge. Only charges with transactionType RESERVE_CAPTURE can be captured. Served by the Mockzilla mock runtime.

Refunds a charge, can also do a partial refund (refunding a smaller part of the payment).

Fetches all charges for a single agreement, including the optional initial charge. Supports filtering on status using query parameter.

Creates a new recurring charge (payment) that will charge the user on the date specified. If the payment fails, the charge will be retried based on retryDays.

Fetch a single charge for a user.

Cancels a pending, due or reserved charge. When cancelling a charge that is PARTIALLY_CAPTURED, the remaining funds on the charge will be released back to the customer. Note if you cancel an agreement, there is no need to cancel the charges that belongs to the agreement. This will be done automatically. Mocked via Mockzilla.

Fetch a single charge just by chargeId, when the agreementId is unknown. Useful for investigating claims from customers, but not intended for automation. This is not a replacement for the normal endpoint for fetching charges: GET:/agreements/{agreementId}/charges/{chargeId}.

Captures a reserved charge. Only charges with transactionType RESERVE_CAPTURE can be captured. Can also do partial captures (captures a smaller part of the payment).

Refunds a charge, can also do a partial refund (refunding a smaller part of the payment).