Introduction
Integrating online forms with line of business applications can be a complex technical requirement. So it is even more complex to be able deliver a user friendly way of delivering this integration by staff that are not trained developers.
eDesigner currently has plug-ins that have enabled live integration to Capita Payments, Northgate Payments and Civica APP without code. This ability is commonly known as 'low code'. But in reality, the way this has been implemented, it is really 'no code'.
The purpose of this guide is to illustrate how integration to payments systems has been augmented in our latest eDesigner build to enable multiple items to be purchased and provide a shopping cart like function.
Again all without code.
We're really happy to provide this functionality to our customers and we hope it is indicative of the value we continue to provide and the boundaries we push to make digital service delivery possible by business users - not IT.
What's new?
The new functionality is comprised of the following enhancements:
1) A new section within the Add Item menu called Payment
2) A drop down of three functions within there that enables one to add:
- Individual items with associated descriptions / prices / fund code / references
- An adhoc user defined amount to pay
- A purchase summary which lists multiple items being bought
3) An enhancement to page rules to be able to show / hide individual/multiple purchasable items based upon a user's selected needs
4) A new 'Payment Setting' button to be able to still cater for single item payment forms
5) An enhancement to the API integration to push the total calculated payment into the payment field in Capita/Northgate Payment systems
6) Enhancement to the API integration to automatically push the summary of the items to be paid for into the Capita/Northgate Payment Confirmation screens.
How to add multiple payments functionality to a form
To illustrate how simple this is, we've built an online form that allows a person to pay for multiple new bins. This form will allow a person to select the specific bins they want and using page rules we can set it so only those bins they need are added to the payment summary.
The following illustrates the new Payment function, which is accessed via the 'Add Item' option in the Designer menu:
When one clicks on the drop-down menu in the payment function the three functions mentioned earlier are shown.
So in this form we've added three purchasable items - Black Bin, Green Bin and Brown Bin. Here is one of those items to illustrate this:
Don't worry about the HTML in the Field Label, this has been done to illustrate the flexibility of this solution in terms of how you can visualise items a person is paying for.
The following outlines what each field is:
|
Element |
What is it? |
|
Field Label |
This is what the customer will see when they’ve selected what they want |
|
Item Description |
This is the description passed to the payment system as the description and what is shown in the payment summary |
|
Item fund code |
This is the payment system’s fund code |
|
Item amount |
This is the amount specific to the item |
|
Item reference |
This is the budget code / payment reference code |
So after the three items were added we then created a drop down to allow a user to select which items they need:
You can see the reason we added HTML for the field label was so that we could have images within the form laid out in a mobile responsive 'card'. So the point here is to illustrate that using HTML and updating CSS allows you to have a lot of customisation over the look and feel of items.
The next thing we did was add page rules such that a person will only see the payment items reflective of the option they've selected. I.e. in the above screenshot it shows all three bins because the option of 'All three bins' was selected. So below we can a different option was selected and thus the payment options are updated to reflect this:
The following illustrates these rules but as the page rules behaviour works the same as now we aren't going to cover this further:
Essentially the rules above ensure each drop down option results in different items/prices being shown.
Adding a Purchase Summary
After doing this we added a Purchase Summary control to the page after that where the above took place. Nothing other than the control needs to be added. It will automatically pick up the values / amounts that were selected previously.
IMPORTANT
A Purchase Summary needs to be on a different page AFTER that where the items were selected. As you can see the total of the three payments is shown as its own item below:
Integration to the Payment System
Now when we press submit we can see the changes made to the integration. As one can see the total value from the payment summary is populated in the amount element when the payment system is invoked:
But importantly when accessing the confirmation screen the user can see how this is comprised:
You have now just seen how we built our first online form with multiple payments and hope it was simple to understand and use.
Other Updates - User-defined purchases
The ability to ask the user for an amount they wish to pay has been added so this can be done on all Payment systems. If you click that you want a user defined amount with the check box shown below it will expand to show additional fields like the regular expression/messages to be shown if the way it is entered is invalid/incomplete - NB whilst you can change the regular expression I'd only do this if there are problems with integration because this regex is what the APIs expect.
There is also the ability to have a user enter a reference and for this reference to have its own regular expression. This will be very useful in ensuring account numbers/license references etc are valid.
The good thing with this field is that you could have a list of payment types a person could make on a page. Then, based upon the option they select show the relevant ad hoc user defined payment element.
Single Payment Settings
Because we now have both single and multiple payment functions there needed to be a way of setting which a form would use. So now when the Design Tools menu is opened you will see there is a Payment Settings button:
This behaves the same as now but is accessed slightly differently.
Non-critical issues we're still working on
1) With the "UserEntryPurchasableItemControl"
If you have a rule that has it is initially hidden on page load and then click next to move to another page, the mandatory validation will get triggered by the javascript even though it is hidden.
2) For repeating sections I have added a property for Maximum repeat (which you can set to between 1 and 20)
If you change this say from 5 to 15 and go back to design mode on the form, sometimes the edit and delete buttons don't work.
I.e. they don't trigger any javascript. You can still move it though and sometimes if you move it to another place on the page the edit / delete buttons will work again