Payment Page - Technical Integration¶
Export Private Key to PEM format¶
The private key can be exported from a Payment Page keystore to PEM format using keytool. The output is in PEM format which can be used directly or via conversion by most load balancers, proxies etc. KeyTool must be run with merchant.jks located in the same folder.
Command to convert JKS keystore into PKCS12
>keytool -importkeystore -srckeystore merchant.jks -srcstoretype JKS -deststoretype PKCS12 -destkeystore merchant.p12
Command to convert PKCS12 keystore into PEM File
>openssl PKCS12 -in merchant.p12 -nocerts -out merchant.pem
- merchant.jks
- merchant.p12
- merchant.pem
Advanced customization¶
Customizing the payment page flow¶
With Payment Page it is possible to adapt the flow to suit your specific needs. The following sub-sections describe options and requirements that must be considered.
Options for where to host the list of payment options There are different required templates depending on what payment methods and options that are intend to be used:
Option 1: (Some) payment options are listed on the merchant site If the merchant wants to display a list of payment options on their own site, and use Worldline Payment Page more as a technical interface to interface with all the banks, the redirect to Worldline should include the selected payment method ID. Refer Request Parameters specific to 3D Secure for information about the PaymentMethodID parameter.
Using iframes¶
It is generally not recommended to embed the Payment Page in an iframe due to browser restrictions on Cookies, as well as restrictions by some Payment Methods like iDeal.
If a tight interaction between the merchant page and the payment flow is needed, the Client Side Encryption and REST API should be considered instead of using Payment Page with iFrames.
Klarna¶
Klarna is an "Open Invoice" payment method. When the Consumer chooses to pay using Klarna then Klarna in effect buys the debt from the Merchant. The merchant is guaranteed payment and it is up to Klarna to make sure the order is actually paid. Klarna does this in several ways; the Consumer can choose to get everything on one invoice to be paid within 14 days, or the Consumer can choose to pay in installments over a period of time. From a payment flow perspective it looks similar to a Card payment.
The Merchant can choose either Authorize (via PaymentPage) + Capture (via API) flow or roll it all into one Debit (via PaymentPage). The Merchant gets fulfillment on Authorize and is then free to ship the product. The actual invoice is sent to the Consumer when the Capture/Debit is sent to Klarna. Since the result is an invoice to the Consumer all items in the order has to be specified. This means that each product in the order has to be represented as a Line Item in the redirect (note that there is a quantity for each line item so in case of several identical products it can be one line item with the appropriate quantity). The sum of all Line Items has to match the sum of the order in the redirect. The Merchant can then choose to Capture only certain Line Items.
The "payment instrument" in Klarna is a combination of Name, Address, Phone number, email, birthday, gender and Social security number (or “Personnummer” in Sweden). Since both shipping & billing addresses are sent to Klarna via PaymentPage or API, the customer cannot change those in Klarna’s end (in Klarna’s hosted payment page). If they differ, Klarna will apply a slightly more strict credit / fraud policy (e.g. trigger strong authentication).
Payment Plans¶
The different variants of Klarna can be dynamically presented to the Consumer at the PaymentPage. Depending on what the Consumer chooses here it can incur a different cost for the Consumer (for example installments over a long time). The order amount is still the same though and the difference is only a matter between the Consumer and Klarna (who now owns the debt). What options to present and the interest rates has to be negotiated between the Merchant and Klarna separately. These options are known as Payment Plans at Worldline, and Klarna calls them Pclasses. Following are the getPaymentPlanResponse parameters:
| Parameter | Comment |
|---|---|
| PaymentPlanCode | The payment plan code describes the length and type of installment that should be used. |
| TotalCost | The total amount that is payable for the purchase, including starting fee, administrative fees and interest rates. |
| MonthlyCost | Calculated monthly cost. |
| AnnualPercentageRate | Calculated annual percentage rate. |
| NumberOfPayments | Number of monthly payments. |
| Interest | Interest rate for payment option. |
| ArrangementFee | Arrangement fee. |
| Surcharge | Surcharge. |
| MinAmount | Minimal amount for the payment plan to be available on template. |
| Type | a) Used to determine whether it is a fixed part payment or flexible part payment. b) Type used is 0 or 1. c) 0 is used for Fixed Part Payment and 1 is used for Flexible Part Payment. |
| Description | Description of payment plans as supplied by Klarna. |
Mandatory parameters¶
There are more mandatory parameters for Klarna than for other payment methods. The parameters can be entered by the Consumer at the payment page: FirstName LastName BirthDate Phone MobilePhone Email Address1 Address2 City ZipCode Country
There is no separate house number and street name. The full address including street name and house number (for NL/DE/AT) is provided in address 1 and address 2.