Payment Methods

Nordic payment methods for recurring businesses.

INFO-Subscription supports recurring payments and invoicing with support for nordic payment methods through a range of integrations with Payment Providers. Infosoft has partnered with multiple different service providers to bring you the best possible results for your recurring payments.

Payment method

Norway 🇳🇴

Sweden 🇸🇪

Denmark 🇩🇰

Finland 🇫🇮

Europe 🇪🇺

Recurring

One-off

Provider

Vipps

✅

—

—

✅

—

✅

✅

Vipps / MobilePay

MobilePay

—

—

✅

✅

—

✅

✅

Vipps / MobilePay

Card

✅

✅

✅

✅

✅

✅

✅

Swedbank Pay / Mollie

AvtaleGiro

✅

—

—

—

—

✅

—

Mastercard Payment Services

Autogiro

—

✅

—

—

—

✅

—

Bankgirot

BetalingsService

—

—

✅

—

—

✅

—

Mastercard Payment Services

eFaktura

✅

—

—

—

—

✅

✅

Mastercard Payment Services

Google Pay

✅

✅

✅

✅

✅

✅

✅

Mollie

Apple Pay

✅

✅

✅

✅

✅

✅

✅

Mollie

SEPA Direct

—

—

—

✅

✅

✅

—

Mollie

EHF (PEPPOL)

✅

—

—

—

—

✅

✅

PEPPOL BIS Billing

OIO/EAN (PEPPOL)

—

—

✅

—

—

✅

✅

PEPPOL BIS Billing

PEPPOL Sweden

—

✅

—

—

—

✅

✅

PEPPOL BIS Billing

Invoice

✅

✅

✅

✅

✅

✅

✅

Native

Email

✅

✅

✅

✅

✅

✅

✅

Native

BYO

—

—

—

—

—

—

—

Bring your own

✅ indicates the method is available in that country/region, or supports that capability. — means it isn’t. Europe covers the wider set of European countries reachable through the card and wallet rails, beyond the four Nordic countries broken out individually. Recurring means the method can be charged automatically on a schedule without subscriber interaction; One-off means it also supports collecting a single payment outside of a running agreement.

As a rule of thumb:

  • Use Vipps or MobilePay for mobile-first consumer checkouts in Norway, Denmark, and Finland.

  • Use Card with Swedbank Pay or Mollie for broad European coverage and recurring charges; Mollie also surfaces Apple Pay, Google Pay, and SEPA Direct Debit where the subscriber’s device, browser, and bank support them.

  • Use AvtaleGiro, Autogiro, or BetalingsService for bank-mandated direct debit in Norway, Sweden, and Denmark respectively.

  • Use eFaktura or EHF/OIO (PEPPOL) for consumer or business eInvoicing where a direct charge isn’t possible or desired.

  • Use plain Invoice or Email when no automated collection is needed, or as the default fallback until a subscriber sets up another method.

  • Use BYO to plug in a payment provider that INFO-Subscription doesn’t natively support.

Your subscription logic doesn’t need to be rebuilt for every payment method: all our integrations support recurring subscription payments/invoicing, and some of them can also be used for one-off purchases without a running agreement.

All of this happens through the use of payment agreements, which serve as an abstraction. INFO-Subscription manages the integrations so you don’t have to.

Payment Agreements

INFO-Subscription attempts to manage all parts of the billing lifecycle in an automated fashion. When a payment demand is generated, and an invoice issued, INFO-Subscription refers to the current payment agreement, in order to determine how to get money from the subscriber.

A payment agreement is a reference between the subscriber and the tenant which allows the tenant to claim payments directly from the subscriber.

Different agreement types provide different capabilities and routines.

All subscribers can have a payment agreement called Invoice. This basically means there is no way to claim the amount so the system does no attempts at generating a payment.

Concretely, this affects one stage of the billing cycle: with an Invoice agreement, no payment request is scheduled after the invoice is issued, so the invoice moves straight to Wait For Payment. From there it follows the normal invoice-based flow — the subscriber pays manually, and if they don’t, the usual reminder/dunning process applies exactly as it would for any unpaid invoice. Invoice (along with Email) is also the fallback agreement subscribers revert to when no other payment method is active.

Properties of a Payment Agreement

All payment agreements have a few important properties

  • A PaymentType: What sort of payment mechanism is this: DirectDebit, Mobile App, Payment Card (VISA/Mastercard etc.), eInvoice.

  • A PaymentProviderType: Which provider is used for the underlying payment mechanism.

  • A reference for more provider specific details.

The PaymentType is mostly a cosmetic/informational property, especially for tenants with only a few integrations or operating countries.

The Payment Provider Type indicates the service provider that INFO-Subscription uses to facilitate the given claims. See the payment methods overview above for the currently supported providers, including country coverage and recurring/one-off support.

For details on adding a custom/external payment provider integration refer to Bring Your Own Payment Provider.

Managing Payment Agreements

There are multiple ways to create a payment agreement for a subscriber.

  • Created during the order registration.

  • Created as a self-service action (initiated via a website or target email campaigns etc).

  • Initiated out-of-band.

Choosing the Right Flow

Scenario

Use this flow

A new subscriber is signing up and choosing a payment method as part of checkout

Create during checkout via order registration — pass paymentAgreementParameters with the order

An existing subscriber wants to add or change their payment method themselves

A self-service action, via the managed self-service client or your own site calling the API directly

The provider registers the agreement in the subscriber’s online bank, outside of your control

Out of Band Agreements and Automatic Agreement Registration (below) — applies to AvtaleGiro, eFaktura, Autogiro, and BetalingsService

You already have agreements in another billing system or an ecommerce platform

Importing Agreements (below)

You need a provider INFO-Subscription doesn’t natively support

Use a custom PSP integration: Bring your own PSP

All of the approaches share the same organization/abstraction model in INFO-Subscription and follow the same flow in terms of the integration/API.

  1. A Provider Agreement is created (the details vary by provider).

  2. A Payment Agreement is created pointing to the provider agreement.

  3. The Payment Agreement is registered for a subscription (sometimes this happens automatically).

The idea here is that each Payment Provider, such as Vipps, Swedbank Pay, Mollie, or AvtaleGiro, has its own peculiar details on how to register an agreement, and each exposes different terminology and properties on the agreements. To abstract away some of these details most of the time, the subscription points to a payment agreement, which in turn points to the provider.

This allows most integrations to just query for the Subscription and Payment Agreement information without worrying too much about the various providers. When a new provider is added, no adjustments are needed to provide general information about these new agreements, only in-depth information requires additional integration.

For details on how to register new provider agreements, refer to the individual provider sections.

A request to create a new payment agreement, sent to the Payment Agreement endpoint, might look like:

{
    "subscriberId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "providerType": "AvtaleGiro",
    "providerAgreementReference": "00000000000011",
    "paymentMethod": "DirectDebit",
    "providerAgreementId": "945a996e-ac8b-4a96-96c3-deb136dc2830"
}

  • subscriberId – the subscriber the agreement belongs to.

  • providerType – which provider handles the agreement, for example AvtaleGiro, Vipps, or EHF.

  • providerAgreementReference and providerAgreementId – identifiers for the underlying provider agreement; which of the two is required, and their exact format, varies by provider, so check the individual provider section for the fields it expects.

  • paymentMethod – the informational PaymentType described above (DirectDebit, Mobile App, Payment Card, eInvoice, etc.); it doesn’t affect how the agreement is processed.

The API returns the created agreement record; use its identifier in the next step, registering the agreement for the subscription, as described in Switching Agreements Manually below.

Switching Agreements Manually

Once a Payment Agreement has been created, switching to this agreement is a simple as assigning it to the subscription.

Note

Agreement management is also built into the Self-Service client and to some degree into the Merchant client.

Out Of Band Agreements and Automatic Agreement Registration

Some payment providers are typically registered in a process not connected to the merchant, and by extension not in their systems. At the current time of writing, this is relevant for the following providers:

For all of the above, the registration will happen, or may happen, in the subscribers online banking solution.

There are different details to be aware of, but in general terms the following process is enacted.

  1. The Subscriber registers an agreement in his/her bank.

  2. A notification is generated to the merchant.

  3. INFO-Subscription registers a ProviderAgreement and a PaymentAgreement.

  4. Once the PaymentAgreement is generated INFO-Subscription will attempt to automatically switch to the created agreement.

At the current time, only subscribers with the Invoice payment agreement are automatically switched. It is assumed that whatever process they entered into is preferable from their point of view until otherwise dictated. At the current time there is no way for a merchant to define a preferred order of payment methods.

Importing Agreements

Sometimes it is necessary to import payment agreements from external sources.

There are several use cases for importing agreements, but the two main scenarios are:

  1. When migrating existing agreements from another billing/subscription system.

  2. Integrating with ecommerce platforms that generate the agreement during the initial sale.

Each provider integration exposes its own endpoint for importing existing agreements. There are some variations, so look to the provider descriptions for the details.

Common for all the scenarios is that once an agreement has been imported for the provider, it should be added as a general agreement, and handled the same way as with new orders or during self-service registrations, as described above.

Payment Providers (PSPs)