moj noms apvs 0116 payout
Technical Spike to understand the Santander Payout service for the provisioning of Cash Payments.
NOTE: BETA Design Spike includes updates for scope of beta
The APVS service has a requirement to pay out to claimants where their claim has been successfully approved.
This includes an option to pay individuals who do not have access to (or will not provide details of) a bank account.
Payout is the cash payments service operated by the Post Office. The post office has a goal to remove all paper from their services and thus driving a move away from Giro Cheques.
Assisted Prison Visits is one Santander's 3 largest customers for cash payments, and therefore are a priority for moving away from giro payments with Payout offered as the alternative product.
Removal of GIRO cheques as a payment option represents the primary external constraining date for the delivery of the new service.
Benefits of this service over GIRO cheques include:
- Reduced instances of recorded fraud
- No requirement to print paper cheques
- Fully managed service (mail, email, text options to send vouchers to customers)
- Clients require that an Post Office Payout portal account to be created. This is used to log on to https://www.postoffice-payout.co.uk
- Files can be uploaded manually against this account via the portal
- Files can also be uploaded automatically to an SFTP server
- This requires the creation of a dedicated SFTP username and password (See below)
- Name of person to contact regarding the account
- Email address associated with the account
- Telephone number of account contact
- Scheme / Sub-scheme information
- Username for SFTP account
Santander will then provide the password for the user and confirmation that the account has been created.
Integration with the Payout service can be facilitated either via an automated Secure FTP delivery or via manual upload to the Post Office Payout Portal.
Files undergo the same internal process of validation and approval regardless of the mechanism by which they are submitted.
The status of files which are being currently being processed can be tracked manually via the portal.
Payments to customers will be recorded in a database table within the schema used by the internal and external web applications.
The diagram below illustrates the process of generating the outbound payment file which is delivered to the Payout SFTP server.
Payment Generation
A new payment will be added to this table whenever a Claim is approved for payment by the APVU Provider. Payout/Cash payments will have be indicated by a Payment Method attribute.
Payments will also have a status to indicate their current state in the payment lifecycle.
Payment records will require a unique reference number to be generated by the APVS system. This is necessary because the Payout service will generate a subsequent reconciliation file to update the payment status (e.g. Cashed, Expired, Cancelled)
Process New Payments
A separate async worker process will run on a configurable scheduled basis to batch process Cash/Payout payments which are in a status which indicates they are newly created.
The worker process will use the contents of this query to generate a new output file conforming to the format specified in the section below.
File Transfer
Once the file for that run has been generated it will be transfered to the configured remote SFTP server directory as specified by the Payout service.
If delivery of the file completes successfully then the final step the worker process needs to complete is to mark any payment records processed as part of this batch to a new status which indicates they are pending payment (E.g. Pending)
All payments which are sent as part of a single file transfer to Payout should be grouped by setting a Batch Id field.
The Batch Id will allow individual files which may need to be re-processed (e.g. if they were rejected) to be identified by support.
The file produced by the APVS system must be a CSV (commat seperated value) text file, adhering to the format specified in the linked document:
The diagram below illustrate the Post Office internal process which generates the cash payment codes:
This process is effectively the same regardless of whether the file was manually uploaded to the Post Office portal or if it was delivered to the SFTP directory.
Information regarding the processing and verification of the file is the same regardless of how the Post Office receive it.
Any notifications of change in status of the file whilst it is being processed by the Post Office will be sent to the named contact(s) for the APVS service. E.g. that a file has been Rejected.
The use of a Batch Id for any given set of Payment records which are transfered to payout can be used to group them for the purposes of updating/fixing issues with the data.
This is expected to be an exceptional task which would be covered by the application support team and not end users.
The Payout service will produce an output data file which conforms to the format above, but with an additional field to indicate the generated voucher code.
This assumes that the APVS solution is taking on the responsibility of code distribution, rather than the Post Office.
In this case, a seperate process will need to be developed which will process load the output file and process it to distribute codes:
Process
The payment code file is generated on the Payout Portal 24 hours after the original output file has been uploaded.
An APVS staff member with access to logon and download the file will need to retrieve this file which takes the form of a CSV file in the format described in the linked sample file. It is identical to the output file except for the inclusion of a field which contains the generated alphanumeric payment code.
The APVS system will need to implement a manual file upload process to allow an authorised staff member to load in the payment code file.
A background async process will be developed to process the contents of this file.
The file will be staged in a database table. Each record will have the content generated for delivery to the recipient via the Notify service.
This will be based on the contact preferences of the Claimant and can be either Email, Letter or SMS.
Content generation will include converting the code into a pre-rendered image of the barcode as described in the section below.
The return file from the Payout service will contain the alphanumeric code used to generate the Barcode for distribution to customers.
This is ultimately an optional part of the scheme as the distribution can be carried out by Post Office (with a cost implication).
The code is in the form of a 13 character alphanumeric sequence.
There is a Royal Mail standard Code 128 which defines how barcodes should be generated.
The linked PDF above details this format in section 6.
This code can be rendered as a barcode by using the associated RM4SCC barcode font.
This is freely available to download from Royal Mail: RM4SCC Font File
The reconcilliation process is outlined in the sequence diagram shown below:
File Format
The Payout service will produce a daily reconciliation report which indicates the status of individual transactions. E.g. cancelled, cashed, expired etc.
Process
The reconciliation file is generated manually via the Payout Portal by an APVS staff member with access to logon and download the file. The reconciliation file will remain available for download on the Portal for 14 days. Outside this timescale the data is retrievable on request.
This takes the form of a CSV file in the format described above.
The APVS system will need to implement a manual file upload process to allow an authorised staff member to load in the generated reconciliation file.
Another async worker process will be developed to process this file and match Pending payout payment records against the system generated reference number supplied to the Payout service in the original output file.
This process will then update the record with the corresponding status (e.g. Cashed, Expired, Cancelled) to indicate the outcome of the payment.
The worker process can be implemented as a Java or Node JS application, running in a separate container with a chron job executing it on a configurable scheduled basis to check the payment table for new payout records to be sent to the external service via Secure FTP transfer.
Logs from the worker should be exported to the log aggregator for monitoring.
The Post Office Payout service is technically understood and provides two alternative options for implementation:
- Post Office handle distribution of codes to claimants
- Post Office return a file containing the generated codes and APVS handles the distribution of codes via the Notify integration
Option 1. will have a higher cost (TBC), but will result in less manual work for APVS.
APVS case workers will need to be manually involved in the Payout process in either case, even though it will be lower for option 1. In both cases the reconciliation of payments needs to be downloaded from their portal and uploaded into APVS.
Outstanding queries:
- Is the process of operating the Payout service outlined in this spike feasible for APVU?
- What are the costs associated with this service and are these acceptable?
- Post Office Payout
- Post Office Payout Technical Documentation (See project Google Drive)