Tag: Payment API

  • New Webhook Service

    Update:

    Tags: , ,

    Introducing:

    • Additional IP addresses sending Payment and DataSet webhooks:
      • 63.182.150.245
      • 3.68.254.130
      • 3.126.194.213

    Integrators are encouraged to limit webhook requests from the IPs listed in this resource: https://info.onlinefundraising.dk/webhooks.json

    Please check this at least once daily.

    During 2026 Q2 we will gradually transition webhook event types to a new dedicated Webhook Service which will relieve the bottlenecks we have seen, which peaked in December 2025: https://status.onlinefundraising.dk/incidents/scxl4lwm38b6

    For more, please see our documentation: https://support.onlinefundraising.dk/hc/en-001/articles/5356622578844-About-webhooks

  • From MobilePay to VippsMobilePay

    Tags: , ,

    Announcing breaking change:

    • The existing Payment Method Type: "MobilePaySubscriptions" will be replaced by: "VippsMobilePayRecurring"

    Integrators are encouraged to account for both existing and replacing Payment Method Types.

    Background

    When Norwegian Vipps and Danish MobilePay merged in March 2024 we chose to extend our existing “Payment Gateway Engine” (a micro service) as the fastest way to support the new VippsMobilePay API without any chances to our Payment API, allowing a smooth transition.

    As OnlineFundraising remained in Denmark we kept the Payment Method Type: "MobilePaySubscriptions" as it were.

    Today OnlineFundraising manages ~600.000 MobilePay Subscriptions, and as we become increasingly relevant for Norwegian organisations we have identified a need to both enhance our ability to scale and incorporate the Norwegian brand: “Vipps”.

    We have therefore been working on a new micro service with a fresh implementation of the VippsMobilePay Recurring API which among other things allows synchronisation of Agreement details, such as plan, description, amount and frequency in the app.

    Migration

    Implementation of the new micro service will involve a migration of existing Subscriptions and Payments from one micro service to another which includes replacing the Payment Method Type per entity in the Payment API.

    We expect the migration to start in April and last until July 2026, one merchant at a time, in a prioritised timetable, and as coordinated with each CRM integrator as possible.

    Integration

    If your integration is creating new Subscriptions with the Payment Session Handler API you may continue to use the Payment Method Type: “MobilePaySubscriptions” until the end of 2026, as we will convert it to “VippsMobilePayRecurring“.

    If your integration relies on Payment Method Type for reporting or similar, please be prepared to receive new Subscriptions and new Recurring Payments with “VippsMobilePayRecurring” sometime in the above mentioned timeline.

    Future transitions

    Please note that this release and migration only involve Subscriptions and their Recurring Payments. Single and External Payments are not included at this stage, but these will be transitioned as the integration progresses.

    Support ofExisting Payment Method TypeReplaced by
    Single Payments
    (currently via PSP)    		MobilePayOnlineVippsMobilePaySingle
    (later)
    Recurring APIMobilePaySubscriptionsVippsMobilePayRecurring
    (upcoming)
    Report API,
    Donations API    		MobilePayExternalVippsMobilePayExternal
    (later)

  • Payment API: paymentRequired and quantities

    Update:

    Tags: ,

    Deprecating:

    • Agreement and Payment property: "paymentRequired"
    • Agreement property: "defaultQuanity"
    • Subscription and AddOn property: "quantity"

    During 2026 we will implement a series of backward-compatible optimisations in the Payment API. These improvements aim to simplify maintenance of the source code, ensure stability, and make it easier for new integrators to work with the Payment API.

    See the previous release.

    Payment Required

    We found that the property “paymentRequired” caused unnecessary confusion and chose to phase it out from various user interfaces during 2024, reducing its usage intentionally. With this update we also ignore the property, should it be provided by integrators.

    The original intention behind “paymentRequired” was to address arrears on an unpaid subscription – for example, when a payment card expired, and the subscription required payment for its service.

    This made sense for commercial products, but not for donations, and thus created unnecessary confusion and complexity in the overall solution.

    Quantity

    Similarly, variations of “quantity” are suited for subscriptions of physical goods, but not for donations, which furthermore added unnecessary confusion.

    With this update we ignore the above mentioned properties should they be provided by integrators.

  • Payment API: Unpaid, expectedTs og First-scheduleTypes

    Update:

    Tags:

    Introducing:

    • Payment state: "Unpaid"
    • Payment timestamp: "expectedTs"

    Deprecating:

    • The follow Agreement Schedule Types:
      • YearlyFirst
      • HalfyearlyFirst
      • QuarterlyFirst
      • MonthlyFirst
      • WeeklyFirst

    During 2026 we will implement a series of backward-compatible optimisations in the Payment API. These improvements aim to simplify maintenance of the source code, ensure stability, and make it easier for new integrators to work with the Payment API.

    State: Unpaid

    The Payment state: “Unpaid” is assigned to Pending payments that have not been charged three months after dueDateTs, without any error detected.

    Common examples are Direct Debit claims with Arion Banki or FI-kort (giro) via Betalingsservice, e.g. FI-kort has been sent by post, but it has not been paid and we have no options to check its status.

    The Unpaid state reflects that no further action will be made for this particular payment, and allows for anonymisation which is prohibited Contacts with Pending Payments. However, should the Payment be paid at a later time, the Payment state will be updated to: “Charged”.

    No webhook is sent when the state is set to “Unpaid”, as we consider this a non-action.

    Timestamp: expectedTs

    The new “expectedTs” timestamp indicates when the payment is expected to be processed and is shared across all Payment Types. In practice, this timestamp corresponds to the following for each Payment Type:

    • Single: “chargedTs“
    • OneOff: “chargedTs“
    • Recurring: “dueDateTs“

    Our aim is to help analysis and pivot across all Payment Types.

    Schedule Types with First

    The following existing schedule types are being deprecated in favour of variants without the suffix “First”:

    • YearlyFirst
    • HalfyearlyFirst
    • QuarterlyFirst
    • MonthlyFirst
    • WeeklyFirst

    Our aim is to narrows the scope of options for integrators.

    The use of “*First” was generally very limited and Agreements with such scheduleTypes have been updated accordingly.

  • Swish Single

    Update:

    Tags: ,

    Introducing:

    • paymentGatewayProvider: "Swish"
    • paymentMethodType: "SwishSingle"

    We recently introduced Swish as a new Payment Gateway, and are now expanding our implementation with Single Payments.

    The API documentation have been updated accordingly:

  • Swish Recurring

    Update:

    Tags: ,

    Introducing:

    • paymentGatewayProvider: "Swish"
    • paymentMethodType: "SwishRecurring"

    We have introduced a new Payment Gateway in Payment API for integration with the Swedish payment service: Swish, available in Forms for Swedish organisations.

    It will later be available in Onboarding for telemarketing and face-to-face in compliance with Swedish law.

    In this initial release, we only support Recurring Payments, but will expand with Single Payments in the near future.

    The API documentation have been updated accordingly: