Credit Card Payments

The general concept is that that the InfoSystems integrates with a payment provider (such as PayEx) to provide the services needed for credit and debet card payments.

Because there is no end-user centric frontend and communication with the end-user is required while registering card information, some integration is needed.

The API provided attempts to hide some of the complexities of integrating with a payment provider, and attempts to streamline the different providers making it easier to switch between providers if needed. So you could say that you integrate with the InfoSystems as a payment provider instead of a specific provider like PayEx.

In general terms, payment providers offer three types of integration:

1. Hosted Window/Terminal

2. Merchant Window/Terminal

3. Callcenter

Each of these provides various pros/cons, but the long and short of it is that currently InfoSystems supports the hosted model because it does not compromise security and does not require PCI compliance.

In the hosted mode (sometimes called the redirect model), the merchant is not storing any critical credit card information as these are entered on a web site hosted by the payment provider. The idea is that the user implicitly trusts the payment provider and the payment provider is the one who is PCI compliant, while the merchant just uses a service. For more details on what this actually entails, refer to the documentation of your chosen provider.

Some basic terminology is in order before proceeding. The various providers uses slightly different terminology about the same things, so we will try to establish a common terminology to use with all providers.

Customer/Card Holder/End User

The person with the credit card, the one buying something

The Merchant

The legal entity that the customer purchases something from. The merchant is the newspaper, and the customer interacts with the merchant by using its systems. Often we will refer to the merchant, when the actual meaning is the IT systems of the merchant (i.e. a web site and the InfoSystems).

Card Issuer/Bank

The bank where the customers credit card was issued. Common examples are Nordea, DNB and Sparbank.

Payment Provider/Provider System

The entity and system that provides communication between the merchant and the bank. Typically the one who saves the credit card information (not required) from the customer on behalf of the merchant. Examples of providers are PayEx, NETS and DIBS.

Agreement Payment

An agreement payment is a payment made on a previously registered credit card. The idea is that upon a purchase, a credit card reference (agreement) is stored by the merchant and that reference can then be used to make purchases in the future. Various providers uses different names for this, NETS calls it EasyPayment, PayEx calls it AutoPay, while the concept it emulates is used in popular online stores like Amazon is called 1-Click purchase. In any event the InfoSystems stores this agreement reference such that it can be used for later purchases, both automatically for subscriptions and manually for external 1-Click purchases.

Provider configuration details

One of the things that is always needed when integrating with payment providers is various configuration details such as a merchant identifier and encryption details. In order to simplify the integration and hide some of the details, these details are now configured in the InfoSystems, and the API methods just requires a reference to a configuration in order to work. This configuration reference is called a PaymentSetupCode. Changing the code will potentially change any values related to the provider (or even the provider). For instance this can be utilised to switch between provider test environments and production environments, such that change from one to the other is just a matter of changing the PaymentSetupCode that is being used.

To obtain a PaymentSetupCode please speak to the people responsible for maintaining the various settings in InfoSystems, they should be able to set up a new configuration or change existing settings.

Recurring payments and agreement payments

Some payment providers has a service they call recurring payments. The idea is that a payment is scheduled regularly (once a month for instance) and the money is automatically withdrawn from the customers credit card. Since the InfoSystems subscription module, is essentially an advanced recurring engine, this functionality is NOT used directly. Instead an agreement reference is stored for the credit card, and when the time comes to start a new period/extend the subscription, a new payment will be requested by the system. This allows for all the flexibility that exists in the paper invoice model where payments can be delayed due to delivery problems, pauses in subscription etc. In short the InfoSystems uses its own recurring model and not the model offered by the payment provider.

Instant- or two phased payments

There are generally two ways of getting money from a credit card. By instantly withdrawing an amount when the checkout is made, or by reserving an amount and withdrawing them when the goods are shipped. Depending on the provider the terminology used is different, PayEx and Nets denotes the instant variant as SALE, while DIBS calls it capturenow. The first phase of a two-phase payment is generally called authorization, and the second part is generally called capture. Infosoft denotes the two flow variations as Instant and Two Phased payments. We recommend to always use the Two Phased variety, but we provide the option for creating instant payments. In case of subscription orders, the actual capture in two phased payments is done automatically when the subscription starts.

The following is a generalized representation of the flow between the card holder/end-user, the merchant and the payment provider. It is not complete, and might contain small differences between providers.

Figure 1: Outline of the general payment process

In short the process can be described as follows

1. The customer makes a purchase/checkout on the newspaper website

2. The website initiates a payment using a InfoSystems web service metod, which in turn initiates a payment at the provider

3. The customer is redirected to the provider website where he/she enters creditcard information and is redirected back to the newspaper website

4. Upon return from the provider, the website completes the payment in InfoSystems, and greets the user with a "Purchase Successful" page.

The payment parts of process outlined above is implemented using two (possibly three) web service methods; StartPayment, CompletePayment and optionally CapturePayment. For the details on using the API in relation to subscription orders, refer to the specific help topics.

Other Resources