Category: Updates

  • Replacement of DAWA with Adressevælger

    Update:

    Tags:

    Introducing in June 2026:

    • addressValidator and addressId in DataSet

    Deprecating in September 2026:

    • dawa_id in DataSet

    Fundraisers can choose to use various services to validate user inputs, including Business Code, National ID, Phone Number and Address.

    In Denmark, we currently validate Danish addresses using Danmarks Adressers Web API (DAWA). However, DAWA is being deprecated on 17th of August 2026 and will be replaced by a new service called Adressevælger. For more, please see:

    The two services operate somewhat differently, but share the same underlying address UUID. You can verify this by looking up our office address using the UUID 0a3f507b-4642-32b8-e044-0003ba298018:

    As part of this transition, we are replacing the “dawa_id” field in DataSet with a new field “addressId“, which is neither service nor country specific.

    If your integration relies on DAWA, please update it to use the new field “addressId” along with the Adressevælger service.

  • Payment API: orderLines and receipt

    Update:

    Tags: ,

    Deprecating:

    • The entity: “Order Line” and thereby the API-endpoint:
      GET /payment/{guid}/orderLines
    • The entity: “Receipt” and thereby API-endpoint:
      GET /payment/{guid}/receipt

    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.

    Background

    When Payment API was introduced back in 2019, OnlineFundraising’s focus was less narrowly defined than it is today. Over time, it has become clear that our sole focus is on charitable organisations and their fundraising for good causes. At the time, however, there were also commercial interests to consider, both then and in the years that followed.

    For that reason, OrderLines were added to support a potential need to present an invoice consisting of order lines, corresponding to a settlement for a given period. In practice, this capability has turned out to be unnecessary for organisations. We are therefore deprecating and removing this functionality to simplify our codebase and make ongoing maintenance easier.

    We recognise that this is not backwards compatible, which we normally strive to maintain. However, since we see virtually no API requests using this functionality, we are taking the liberty of phasing it out. Please do not hesitate to contact us if you have any questions about this change.

  • New Communication Event Types

    Update:

    Tags:

    Introducing Communication Event Types:

    • PaymentMethodSignupFailed
    • PaymentRecurringFailed

    These will allow organisations to configure additional automatic retention emails sent to donors based on specific scenarios which predominately are incorrect bank details for Betalingsservice and erroneous payment method applied in VippsMobilePay respectively.

  • 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
      • 3.124.137.18

    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

    Update:

    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 September 2026, one merchant at a time, in a prioritised timetable, and as coordinated with each CRM integrator as possible.

    During the migration updated webhook events will be sent for:

    • Recurring MobilePay Payments in 2026
    • All MobilePay Subscriptions
    • All MobilePay Payment Methods

    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.

  • SMS with Custom Fields Service

    Update:

    Tags: ,

    We have expanded the existing user interface with the Custom Fields Service.

    Later, as with other subsystems, we will update the user interface in terms of design and user experience.

  • 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.

  • Updated Support of VippsMobilePay’s Donation API

    Update:

    Tags: ,

    We have expanded Payment Receiver and its integration with VippsMobilePay’s Donations API, upgrading from v1 to v2, making authentication easier with the user interface.

    Their Donations API enables the forwarding of donors’ full name and phone number to the organisation (at a cost) in contrast to regular VippsMobilePay Number payments.

    Additionally, with this update we also note whether or not each payments is part of “Faste Donationer” which will later be used to mirror those subscriptions and their recurring payments.

    Contact

    Full name is provided without split into first name and last name as these are not available from the Donations API.

    {
    "contactType": "individual",
    "name": "Full name",
    "msisdn": "4512345678",
}

    Payment

    Meta data provides insight into Number (recipient), custom reference from VippsMobilePay’s portal, and agreement.

    {
    "paymentMethodType": "MobilePayExternal",
    "paymentGatewayProvider": "PaymentReceiver",
    "paymentGatewayTransactionId": "10000000000",
    "paymentMethodAccountingCode": "MobilePayExternal",
    "metaData": {
        "mpe": {
            "message": "My message",
            "ledgerId": "123456",
            "recipient": "DK:654321",
            "agreementId": "d1e2d365-1433-471c-be96-xxxxxxxxxxxx"
            "externalReference": "ORG-REF-1234"
        }
    }
}

    Payment Method

    {
    "paymentMethodType": "MobilePayExternal",
    "paymentGatewayProvider": "PaymentReceiver",
    "metaData": {
        "mpe": {
            "recipient": "DK:325858"
        }
    }
}

    DataSet

    A summary of registered details are available from the DataSet API.

    {
    "jsonElement": {
        "formResult": {
            "name": "Full name",
            "msisdn": "4512345678",
            "message": "My message",
            "recipient": "DK:123456",
            "externalReference": "ORG-REF-1234",
            "agreementId": "d1e2d365-1433-471c-be96-xxxxxxxxxxxx"
        }
    }
}

  • Updated User Interface: Export

    Update:

    Tags: ,

    As part of our ongoing and gradual improvement of the user interface, we have updated the appearance of the following menu items:

    • Export

    The update includes a new design and several adjustments to enhance the user experience including:

    • Full history of past exports
    • Ability to isolate own exports from your colleagues
    • Ability to reuse previous exports as a filter for a new export
    • Support of Custom Fields Service