> For the complete documentation index, see [llms.txt](https://ieg4.gitbook.io/edesigner-new/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ieg4.gitbook.io/edesigner-new/no-code-integrations/payment-systems/access-group-pay360-and-paye.net.md).
# Access Group - Pay360 and Paye.net
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. This ability is commonly known as ‘low code’.
The way this functionality to integrate online services with your payment system has been designed, it is beyond low code; it's ‘no code’.
### High Level
The functionality we provide is comprised of five functions. These provide the ability to:
1\) Add fixed value payment items that a person can choose to buy
2\) Add a user entered value control where the citizen can type how much they wish to pay
3\) Add a shopping basket that tallies up all payments before submission - the payment summary
4\) Prepopulate the Capita Pay360 interface with name, address etc. from the eDesigner form
5\) Send internal email(s) upon submission per form
To add a payment element, one simply clicks on Add Item in the Designer function and then clicks on the payment tile:
There are then the following three options:
### Payment Items
A payment item is a fixed price item that a person can buy.
If you choose to add a payment item the following options are presented:
Once added to the form it will appear like so:
{% hint style="info" %}
You should use [**Page Rules**](/edesigner-new/building-services/adding-rules/page-rules.md) to dynamically hide/show the payment amount the person needs to pay.
{% endhint %}
The relevant fields you can add and what they are:
| **Element** | **What is it?** |
| ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| Field Label | This is what the customer will see when they’ve selected what they want |
| Amount | The amount one needs to pay for the item |
| Tax included | The ability to set a VAT amount against an item |
| Currency Symbol | Used purely for those taking payments in other countries |
| 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 |
Where the 'Tax included' check box has been ticked, the user is able to provide a breakdown of the VAT code (as held in Capita Pay360), the % and the amount:
For this option there are a variety of **additional** fields that relate to controlling what a user entered amount looks like and its label. I.e. the format of the numbers they can enter is controlled by a regular expression.
{% hint style="info" %}
We'd suggest you keep this as it is, as it's the standard format for currency based entry.
{% endhint %}
You can also add validation and mandatory warnings too.
You can configure it such that there is a fixed **item reference** or enable the customer to enter this i.e. Council Tax account number. If the check box 'User entered reference' is clicked the following additional fields are displayed for completion:
| Field | What it does |
| ---------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Reference field label | Tells the citizen what to enter e.g. Rent account number, overpayment reference |
| Reference field minimum length | The minimum length of the reference they need to enter |
| Reference field maximum length | The maximum length of the reference they need to enter |
| Reference field regular expression |
The ability to control the format well beyond the min/max settings about.
To learn more about regular expressions have a read below:
To search for examples of regular expressions - so you don't need to learn them - please see here:
|
| Reference field validation error message | If the citizen enters a value that is too short/long or doesn't meet the rules of the reference as defined by the regular expression, you can control the content of the message presented. |
| Reference field mandatory warning | If the citizen doesn't enter a value, you can control the content of the message presented. |
| Include help text for reference field | If checked, you're able to then provide help text for your custom reference field. |
### Purchase Summary
A payment summary automatically tallies up any payment relevant payment items/user entered amounts and acts like a shopping basket.
The only thing required when adding a payment summary is a field id and should you support a different currency (unlikely!) the ability to change the currency symbol:
This is presented like so where two items were requested on earlier pages:
{% hint style="warning" %}
**Important**
When adding a payment summary remember that it:
a) MUST be after any pages containing payment items/user entered payments
b) MUST be on a page that does not contain any payment items/user entered payments
{% endhint %}
{% hint style="success" %}
You can have other content on a payment with a payment summary - just not other payment items.
{% endhint %}
### Internal Email Receipts
It is possible to send an email receipt of the payment on any form to an email addresses or addresses as set by you.
The functionality is accessed using the 'Payment Settings' button on the Designer menu:
Here you can tick the box to enable the function - 'Email payment receipt internally'. Then use the 'Add a new email' button to add the email address(es) that should receive the receipts:
{% hint style="danger" %}
**IMPORTANT**
This email is actually sent from the Capita system. This functionality essentially tells Capita who to email.
Therefore the functionality and the content within the email itself is controlled entirely by the Capita Pay360 application.
You should therefore raise any issues with these emails with Capita support.
{% endhint %}
### Pre-population of personal content (non-payment item related)
Unlike most payment systems where one passes the amounts and things to buy, there is a stage which asks about name, address, email etc. in the Capita Pay360 flow.
To ensure these details are automatically populated from the eDesigner form, there's functionality to ensure that any of the following can be passed to the Capita payment system :
* PersonTitle
* Firstname
* Surname
* Email
* AddressFieldsAddressLine1
* AddressFieldsAddressLine2
* AddressFieldsAddressLine3
* AddressFieldsAddressLine4
* Postcode
Ultimately ensuring that it is quicker to make / take a payment from a form. The functionality is accessed using the 'Payment Settings' button on the Designer menu:
Once in here one can see there is a new 'Pre-populate customer details in payment system' option:
If this is checked/ticked then the following fields (using the standard fieldids) from the 'Standard' or 'Blank' **Who Are You** page will be used to to pre-populate the Capita payment screen.
* PersonTitle
* Firstname
* Surname
* Email
* AddressFieldsAddressLine1
* AddressFieldsAddressLine2
* AddressFieldsAddressLine3
* AddressFieldsAddressLine4
* Postcode
There is also an option to pre-populate these pieces of data from any page within the form. To do so you need to check the **'Override default 'Who are you' field XPaths'** option.
{% hint style="success" %}
You don't need to override the defaults and therefore have to delve into the realm of XPaths. It's specifically if you want to use field ids on pages that are not the standard ones.
{% endhint %}
An [XPath](https://www.w3schools.com/xml/xpath_intro.asp) is a technical term to indicate which field on which page of the form you want to refer to.
So in this case the XPath can be used to override the standard behaviour if:
a) You don't have a WhoAreYou page
b) The details to pre-populate are on a later page.
The UI is illustrated below:
To help give an example let's say you have built a page called My Information and you want to use the email address from that page in the pre-population of Capita. If you go to that page you will see its XPath name in the URL.
I.e. this form is PAYMENTTEST, the page it is on is myinfo as that is what is shown in the URL:
### 
So in the XPath description we need the page id to be myinfo:
page\[@id='myinfo']/....
But this only tells eDesigner which page the field is on. The next thing you need to do is add the field id for the field you want to map. So if the Field ID for the form is myinfoemail, as shown in the screenshot below:
The XPath override value would therefore be:
page\[@id='myinfo']/myinfoemail
We can see that we have adjusted which field will be used to pre-populate Capita by placing the above into the Email override field:
### Capita Pay360 SCP Set Up
**CapitaPaymentEndPointAddress**
This is the URL end point fo the payment system's URL. eDesigner enables you to build forms that integrate to payment systems without any technical knowledge.
{% hint style="warning" %}
**You get this info from Capita.**
{% endhint %}
**CapitaPaymentIdentifier**
This is first of three identifiers for Capita Payment system integration.
{% hint style="warning" %}
**You get this info from Capita.**
{% endhint %}
**CapitaPaymentSiteId**
This is second of three identifiers for Capita Payment system integration.
{% hint style="warning" %}
**You get this info from Capita.**
{% endhint %}
**CapitaPaymentHmacKeyId**
This is third of three identifiers for Capita Payment system integration.
{% hint style="warning" %}
**You get this info from Capita.**
{% endhint %}
**CapitaPaymentHmac**
This is a long security code which needs to be added to finalise payment integration.
{% hint style="warning" %}
**You get this info from Capita.**
{% endhint %}
**CapitaPaymentCustomVatCodeEnabled**
We noticed that the Custom VAT code was not being passed across to Capita Pay360 and as a result we've added a new setting:
When true this will ensure that the VAT code will be passed to the Capita Pay360 application.
**CapitaPaymentZeroVatAmountEnabled**
If the VAT rate was 0 we were not sending anything but Capita Pay360 needs zero to be sent. So this setting when true will ensure 0.00 is sent when the VAT rate is 0.
{% hint style="danger" %}
**Important**
The thing to also be aware of is that we need to set your payment preference to Capita Pay360. So if you wish to use this function please tell us at:
{% endhint %}
{% embed url="" %}
### August 2024 update
The following functionality has been included at release 2.16 of eDesigner.
**Pay 360 Accepted Card Types**
Within the eDesigner Payment Item configuration a new tick box is displayed to allow the payment item to be restricted to debit card payment only:
When this option is selected it applies to the whole basket on the Pay 360 Payment Portal. This means that if the eDesigner form supports multiple payment items and a payment item is selected that can only be paid for using a debit card, this validation will be applied to the whole basket on the Pay 360 Portal.
If the user selects a payment item that can only be paid for using a debit card and then enters a credit card in the payment portal the payment portal displays a message as below:
Please note that this functionality is currently only available for Pay 360 integrations.
## May 2026 Update - Paye.net
From Forms version 2.19 support has been added for Access Group paye.net payments used by councils for handling payments made over the telephone. The council needs to arrange set up of paye.net through Access Group including support for the integration. Integrations have been developed against Paye.net Portal Interface Specification Version 11.1 January 2020
The following Settings are used when paye.net is used:
| Setting | Used for |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| PaymentProviders | Configured by IEG4 Support to enable multiple payment providers to be supported. |
| CapitaPayeNetSiteId
| The Site Id for paye.net |
| CapitaPayeNetHmacKeyId | The HMAC Key Id for paye.net |
|
CapitaPayeNetHmac
| The HMAC for paye.net |
| CapitaPayeNetEndPointAddress
| The endpoint url for paye.net for test and live |
| CapitaPayeNetLoginName
| The login name for the user in the invoke request. This user must exist in paye.net. |
| CapitaPayeNetLoginPassword
| The password for the login user |
| CapitaPayeNetConsortiumCode
| The Consortium code for paye.net |
| ServiceViewPaymentProvider | The name of the Payment Provider for agent payments taken from the PaymentProviders configuration Setting. |
{% hint style="info" %}
Note: Paye.net integration is available as a standard plug-in for eDesigner and Waste Product forms but IEG4 Support need to enable this for your environment and configure the PaymentProviders before it can be used.
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://ieg4.gitbook.io/edesigner-new/no-code-integrations/payment-systems/access-group-pay360-and-paye.net.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.