Skip to main content

Recurring PSP API changelog

note

This page covers Recurring API changes that are specific to PSP integrations. There may be additional changes that apply to all Recurring API integrations — see the Recurring API changelog.

July 2026​

  • The v4 charge endpoint for reporting a payment outcome has been renamed from POST:/recurring/v4/agreements/{agreementId}/charges/{chargeId}/finalize to POST:/recurring/v4/agreements/{agreementId}/charges/{chargeId}/result. The behavior is unchanged apart from the error object below.
    • The error.retry field is now required when reporting a FAILED result — send true if the payment may be retried, false otherwise.
    • The error.message field is now optional.
  • DIRECT_CAPTURE is now supported for the initialCharge on PSP agreement sign-up. The initial charge is captured for its full amount automatically once the sign-up CIT succeeds, going straight to CHARGED.
    • Only full capture is supported. If you need partial captures, use RESERVE_CAPTURE and the Capture charge endpoint.

June 2026​

  • The PSP-only Create PSP charges endpoint has the following changes:
    • Returns retryable item-level failures in a separate retryableCharges array.
      • This applies to transient errors where the outcome is uncertain, such as processing_timeout and technical_error.
      • These charges can be retried with the same agreementId + chargeId pair.
    • Requires a type field on each charge, distinguishing unscheduled from scheduled charges:
      • UNSCHEDULED: due must be omitted, and cardInfo is returned directly in the response.
      • RECURRING: due is required (at least one day in advance), and cardInfo is not returned. Fetch it from Get payment info on the due date (see the entry below).
      • The maximum number of charges per batch has been reduced from 100 to 50.
    • Caps the due date of a RECURRING charge at 31 days from creation. A due date further out is rejected in failedCharges with due_date_too_far.
    • Accepts an optional retryDays field on RECURRING charges.
      • For PSP charges, retryDays sets how many days after the due date the charge stays payable — i.e. how long payment info stays available from Get payment info so you can retry the payment — before the charge is automatically failed (0–14 days).
      • If omitted on a RECURRING charge it defaults to 14. For UNSCHEDULED charges, retryDays must be omitted or 0.
      • Two new item-level error codes can be returned in failedCharges: retry_days_invalid and retry_days_not_allowed.
      • Added support for DIRECT_CAPTURE charges on the Create PSP charges endpoint. Previously only RESERVE_CAPTURE was accepted.
    • A DIRECT_CAPTURE charge is captured for its full amount automatically once you finalize it with status: SUCCESS — it goes straight to CHARGED with no separate capture call.
    • Only full capture is supported for DIRECT_CAPTURE. If you need partial captures, create the charge as RESERVE_CAPTURE and use the Capture charge endpoint.
  • Added a new PSP-only v4 endpoint, Get payment info, for fetching payment info for DUE charges. This is needed for scheduled RECURRING charges created above, where payment info is not returned in the initial Create PSP charges response.
    • Fetching payment info on demand avoids storing card data and ensures you always get the most up-to-date payment info for the agreement and charge.
    • For unscheduled charges, payment info is still returned directly in the Create PSP charges response.
    • Like the other v4 endpoints, this is PSP-only for now and enabled in the Merchant Test (MT) environment.
  • The PSP-only Finalize charge endpoint now requires Get payment info to have been called first for a RECURRING charge.
    • This ensures you perform the payment with the latest payment info rather than stale data.
    • Unscheduled charges are unaffected — you already receive their card info in the Create PSP charges response.
  • The PSP-only v4 charge endpoints now have rate limits, consistent with the rest of the Recurring API. See: Rate limits.

May 2026​

  • Added initial support for Payment Service Providers (PSPs).
    • This is only enabled in the Merchant Test (MT) environment for now; PROD will be enabled when the first PSPs have a validated and tested integration ready.
    • PSPs are a new merchant type, separate from existing direct merchants. PSPs process payments on behalf of their onboarded merchants, whereas Vipps MobilePay processes payments for direct merchants (i.e., all current integrators).
    • This change affects all payment flows in Recurring—three customer-initiated (CIT) and one merchant-initiated (MIT):
      • Agreement sign-up with initial charge (CIT)
      • Agreement sign-up without initial charge (CIT)
      • Payment source updates (CIT)
      • Charges on existing agreements (MIT)
    • PSP merchants must include the new cardPassthrough object when creating an agreement. See Agreement sign-up for more information.
      • This is a PSP-only field—direct merchants will get a 400 error response if this is included in the request body.
    • All affected v3 endpoints and their changes are listed below:
    • Two new v4 endpoints have been added for PSP merchants:
      • Create PSP charges: Batch create PSP charges. Each successful charge returns the card data (network token, optionally the encrypted PAN) needed to process a MIT payment.
      • Finalize PSP charge: Report the outcome of a MIT payment, so it can be applied to the corresponding charge and shown to the user in the app.
      • The v4 endpoints are PSP-only for now; they may be extended to direct merchants in the future.
    • As part of this change, three new currencies have been added: GBP, USD, and SEK.
      • PSP merchants can use all supported currencies: NOK, DKK, EUR, GBP, USD, and SEK.
      • Direct merchants must continue to use NOK, DKK, or EUR; attempting to use the new currencies will result in a 400 error response.
Last updated on