Category: Updates


  • New Webhook Service

    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


  • Payment API: paymentRequired and quantities

    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

    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

    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

    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

    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

  • Swish Single

    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:


  • Updated User Interface: Settings

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

    • Settings

    The update includes a new design and minor adjustments to enhance the user experience.


  • Custom Fields Service

    We have introduced a new micro service: “Custom Fields Service”, which centralises Custom Fields used across Forms, Onboarding, SMS and custom integrations.

    As new Custom Fields are added – for example in Forms – they will be registered and later used to guide the addition of the same Custom Fields in other micro service, such as Export or Communications.

    The menu item for Custom Fields Service is located under “Data”.


  • Updated User Interfaces

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

    • Webhook
    • Email History
    • Payment Receiver

    The update includes a new design and minor adjustments to enhance the user experience.