Recently I made my first baby steps with the new Payment API and I immediately encountered a problem that left me helpless. I realized that there is no Verify Configuration
button anymore in my reach. I also could not define any configuration parameters visible in the Preferences
tab of the payment service because everything is pushed in the managed services… Why this button is so necessary in real connectors after all? Is this just because a basic web-form-like validation is applied when you press it or something else goes on under the hood?
In this post I’ll try to reveal the functionality hidden behind the button in the Klarna and PayPal PLUS connectors.
Klarna
On the surface Klarna seems almost like one of ours blue-print payment connectors in which you enter PII data on step 3 of our checkout. What is quite unusual is that the edit template of the PII is very different depending on the combination of the country of the invoice address and the extras which are enabled in the merchant’s account in the system of Klarna. The country specifics are not relevant to my post. More interesting are the other details. Let’s have a look at the next screenshot. It shows the edit PII template for a sample German shop (do not pay attention to the localization at this moment).
The customer may choose between several invoicing plans. For each option there is some data concerning the financial conditions which are relevant for the plan. For example in “Jetzt einkaufen – in 5 Monaten zahlen” (Buy now – pay in 5 Months) the interest rate is 0% but the monthly fee is 29 EUR. All these data – the different invoicing options, the rates, fees etc. is not static and is downloaded from Klarna and stored in JSON format in the shared FS. The data can even change from time to time. Here is a sample snippet:
{
"description"
:
"Jetzt einkaufen - in 5 Monaten zahlen"
,
"months"
: 0,
"startfee"
: 0.0,
"invoicefee"
: 29.0,
"interestrate"
: 0.0,
"minamount"
: 0.0,
"country"
:
"DE"
,
"id"
: 3444,
"type"
: 4,
"expire"
: 0,
"eid"
: 1395
}
Verify Configuration
was pressed (see below).
PayPal PLUS
The PayPal PLUS connector also relies heavily on the ‘Verify Configuration’ button. In fact even more than the Klarna connector. There are some configuration parameters which are sent to PayPal when the button is pressed. They are used for the creation of the so called “experience profile”. The experience profile defines the logo of the shop and its title in the PayPal hosted pages. But there are some more settings which are not visible in the back-office and on which we send. E.g. we forbid the change of the shipping address on PayPal side – a functionality which we do not want to support within our connector!
Note: all these settings can be changed runtime by the shop manager.
Here are the configuration settings in the back-office:
Here is how the create experience profile request looks like (REST and JSON are used):
{
"id"
:
"XP-DYCS-KBN4-SN9B-UUVA"
,
"name"
:
"PrimeTech-PrimeTechSpecials"
,
"input_fields"
: {
"allow_note"
:
false
,
"no_shipping"
:
2
,
"address_override"
:
1
},
"presentation"
: {
"brand_name"
:
"Pray Pal"
,
"locale_code"
:
"US"
}
}

Thoughts
For a long time I’ve been suspicious about the “Managed Services Framework”. It hides behind some pains. The decision to couple the payment services with the managed services was a bad news for me. I even had a chance to observe the bewilderment in the eyes of our Turkish partners while they tried to find their way through the maze of duplicated classes. Now on the table lies an urgent question…
What are we going to do now?
I guess we have no much room for action right away. We need to migrate the functionalities I talked about and we must do that relatively soon. There should be a button somewhere which is clickable by the business users. The common sense probably encourages us to couple the payment and managed services frameworks even more by providing a Verify
button in the managed services framework. It is questionable when this will happen. And I feel really chilled about the complexities which will arise around the storage and retrieval of the data downloaded from the PSP (e.g. the P-Classes and the experience profile ID) if we get this button to work… I’m afraid it will be complicated.
What is more realistic is to have a new capability for verification of the configuration. This will work. The price is that user experience will suffer terribly. The button ‘Verify configuration’ will be detached from the configuration values. Imagine that the switch of your reading lamp is located in your basement. Not really nice, is it? If I make a typo in the configuration I will have to go back to the service (possibly across the channels) fix it, then go back and try if everything works. And if there is a specific error message, e.g. “Your merchant ID is wrong”? The business users won’t be inSPIRED.