Accept PayTo Payments through own payment page - [Australia only]

Introduction

This document will guide you through the PayTo Payments platform which is a new way for businesses to initiate near real-time payments from bank accounts.

Steps

In order to begin and understand the API workflow of creating agreements and submitting payments via PayTo, the typical API flow is outlined below:

Add a New Payer
1. A payer record must be created firstly in order to have a PayTo Agreement created.
2. Use this endpoint to create a payer record and map the payer between both platforms.
Agreement Create
1. Use this endpoint to register a new PayTo Agreement. The approval, processing and acceptance of the new agreement is performed asynchronously - you will need to be subscribed to our PayTo Agreement event webhooks to be notified of whether the agreement was approved by PayTo and whether or not your customer has accepted the agreement.
Agreement Lookup
1. Returns the full details, including the current status, of the agreement with the given reference.
Payment Submit
1. This endpoint will submit a new PayTo Payment for an existing agreement. The processing of the new payment is performed asynchronously - you will need subscribe to our PayTo Payment event webhooks to be notified of the result of the transaction.
  1. Note that the agreement must be in the ACTIVE status for payments to be able to be processed for it.
Payment Lookup
1. Returns the full details, including the current status, of the PayTo Payment with the given reference. Only payments processed within the last 6 months can be looked up using this method - use Transaction Search for older payments.
Agreement Status Update
1. Can be used to update the status of an existing agreement. The processing of the status change is performed asynchronously - you will need subscribe to our PayTo Agreement event webhooks to be notified as to whether or not the status change was successful.
Setup Webhooks
To set up webhooks for testing and production the below will need to be setup:
1. Webhook Url: You provide us a single URL (must be https://) to which we will POST all our web messages for all event types.
2. Shared Secret:
  - Production: This is a randomly generated 88-character string that is unique to your business which we will generate and provide to you.
  - Sandbox: Our Integrations/Implementations team will provide the credentials to you for testing

To test agreement acceptance and trigger payment results, please follow our guide documented below:

Testing Help Desk in Sandbox Portal

Step 1 - Add a New Payer

API

POST Add a new Payer

A payer record must be created firstly in order to have a PayTo Agreement created.
Use this endpoint to create a payer record and map the payer between both applications.
- Minimum fields in Payer Property:
  - ‘UniqueReference’
  - ‘FamilyorBusinessName’
  - ‘GivenName’
  - ‘Email’

Refer to Payer Input Model for more information around the API properties.

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/payers

JSON

{
    "UniqueReference": "PayToPayerTest1",
    "GroupReference": "PayToPayerTest1",
    "FamilyOrBusinessName": "Smith",
    "GivenName": "Bob",
    "Email": "test@test.com",
    "Phone": "0733331111",
    "Mobile": "0411123123",
    "Address": {
      "Line1": "1 Test St",
      "Line2": "Test Building",
      "Suburb": "Testville",
      "State": "QLD",
      "PostCode": "4001",
      "Country": "AUS"
    },
    "ExtraInfo": {
      "XeroAutoDebitEnabled": false
    },
    "Audit": {
      "Username": "Example-User",
      "UserIP": "1.2.3.4"
    }
  }

Example Response

JSON

{
  "payerId": "135032",
  "uniqueReference": "PayToPayerTest1"
}

Step 2 - Agreement Create

API

POST Agreement Create

Use this endpoint to register a new PayTo Agreement. The approval, processing and acceptance of the new agreement is performed asynchronously - you will need to be subscribed to our PayTo Agreement event webhooks to be notified of whether the agreement was approved by PayTo and whether or not your customer has accepted the agreement.
- Minimum required fields:
  - ‘AgreementUniqueReference’
  - ‘PayerUniqueReference’
  - ‘PayerName’
  - ‘Description’
  - ‘Agreement Purpose’
  - ‘PayIDType'
  - ‘PayID’
  - ‘PaymentAmountType’
  - ‘PaymentAmount’**
  - ‘PaymentAmountMax’**
  - ‘ValidFromDate’
    - Date format: YYYY-MM-DD
  - ‘ValidToDate’**
    - Date format: YYYY-MM-DD
  - ‘FrequencyType’

** = Conditional (Required if property is specific value)

Refer to Agreement Input Model for more information.

Refer to Agreement ID Model for more information.

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/agreements

JSON

{
     "AgreementUniqueReference": "PayToPayerAgreementTest1",
      "UniqueReference": "PayToPayerTest1",
      "PayerName": "Bob Smith",
      "PayerIsBusiness": "false",
      "Description": "This is an example for a PayTo description",
        "AgreementPurpose": "OTHR",
        "PayIDType": "EMAL",
        "PayID": "test@test.com",
        "PaymentAmountType": "VARI",
        "PaymentAmountMax": 1000.00,
            "ValidFromDate": "2024-07-09",
            "ValidtoDate": null,
            "Frequencytype": "ADHO",
        "AllowAutomaticExtension": true,
        "IsAttended": false,
        "ActionRequestedByTime": "2024-07-30T10:00:00+10:00",
    "Audit": {
      "Username": "Example-User",
      "UserIP": "1.2.3.4"
    }
  }

Example Response

JSON

{
    "agreementUniqueReference": "PayToPayerAgreementTest1",
    "agreementID": "505f58f8-1ad8-4648-aba2-088d1efa0510"
}

Agreement Input Model

Property	Type	Description
`AgreementUniqueReference`*	string	A reference/ID that will uniquely identify this particular agreement within your systems. Must be unique for each business.
`PayerUniqueReference`*	string	Each agreement must be attached to a Payer that you have previously registered - set this field to your unique reference/ID for one of your existing payers to enable it to be linked.
`PayerName`*	(string - 64 max length)	The full name of the person or business that is going to be making the payments.
`PayerIsBusiness`	bool	set this to true if the payer is a business rather than an individual person [Default: False].
`Description`*	(string - 140 max length - basic alpha numeric text only)	Narrative describing what the payments of the agreement are paying for. Should be concise and clearly recognizable by the payer to encourage them to accept the agreement.
`AgreementPurpose`*	enum	Specifies the general purpose of the payments for this agreement. Allowed values: `DEPD` - Dependent Support Payments `GAMP` - Gambling Payments `GOVT` - Government Payments `LOAN` - Loan Payments `MORT` - Mortgage Payments `OTHR` - Other Service Payments `PENS` - Pension Payments `PERS` - Personal Payment `RETL` - Retail Payments `SALA` - Salary Payments `TAXS` - Tax Payments `UTIL` - Utility Payments
`PayIDType`*	enum	The type of Pay ID that the payer has provided. Allowed values: `EMAL` - Email address A valid single email address. Must match regex: `^(?:[a-z0-9!#$%&'+/=?^_{ `TELI` - Telephone Number Required format: Starts with "+" followed by the country code (from 1 to 3 digits) then a "-" followed by any combination of numbers (e.g. +61-417123456). Must match regex: `^\+[0-9]{1,3}-[1-9]{1,1}[0-9]{1,29}$` `AUBN` - Australian Business Number (Required format: A 9 or 11 digit number.) Must match regex: `^((\d{9}) `BBAN` - Australian Bank Account number (Required format: Numeric digits only with BSB (6-digits) followed by Account Number.) Must match regex:`^(\d){10,16}$`
`PayID`*	string	The Pay ID that the payments will be debited from. It’s value must match the type specified in `PayIDType` (see above for format requirements for each type).
`PaymentAmountType`*	enum	The way in which payment amounts will be calculated for this agreement. Allowed values: `BALN` - Balloon - Regular payment amounts are fixed with a large final payment amount. `FIXE` - Fixed - Ongoing payments are always fixed to the same amount. `USGB` - Usage Based - Payment amount varies based on service usage. `VARI` - Variable - Payment amounts are always variable and are at the discretion of the business.
`PaymentAmount ^`	decimal	The standard payment amount of all payments for this agreement. Is [Required] when `PaymentAmountType` is `FIXE`
`PaymentAmountMax ^`	decimal	The maximum amount that can be processed per payment. Is [Required] when `PaymentAmountType` is `VARI` or `USGB`
`PaymentAmountFirst`	decimal	Set this if the first payment amount is going to be different from the regular ongoing amounts.
`PaymentAmountLast`	decimal	Set this if the last payment amount is going to be different from the regular ongoing amounts.
`ValidFromDate`*	Date	Date from which the agreement comes into effect and payments can start to be processed on it.
`ValidToDate ^`	Date	Date by which the agreement will be finalized and the final payment for this agreement is expected to have been processed. Is [Required] when `AllowAutomaticExtension` is `false.` Must be set to `null` when `AllowAutomaticExtension` is `true.`
`FrequencyType`*	enum	The frequency by which payments will be processed for this agreement. Allowed values: `ADHO` - Adhoc `ONEO` - One-off `INDA` - Intra-Day `DAIL` - Daily `WEEK` - Weekly `FRTN` - Fortnightly `MNTH` - Monthly `QURT` - Quarterly `MIAN` - 6 Monthly `YEAR` - Annually
`AllowAutomaticExtension ^`	bool	If this agreement is being set up with a fixed end date, this can be set to true to indicate that the agreement can be renewed under the same terms for a new period after the end date is reached. If set to `false` then `ValidToDate` must be provided.
`IsAttended ^`	bool	Set this flag to true if you have a scenario where you want the agreement to be processed and approved as quickly as possible, such as where you are creating agreements as part of a process where you must wait in real-time for your customer to approve an agreement before proceeding [Default: `False`]. Note that this flag merely specifies to PayTo that you would like this agreement handled as a high priority - it doesn't guarantee that it will be processed any quicker.
`ActionRequestedByTime`	DateTime	This can be used to specify to your customer that you want them to complete their approval of the agreement by this specified date/time. Note that this not enforced by PayTo - it is used only to display some sort of waiting countdown timer on the payer’s banking app to encourage them to complete it by the specified time. If you want the agreement to be voided if not accepted within a particular period, you will need to use the Agreement Status Update endpoint to cancel the agreement.
`Audit`	model: Audit	Can be used to provide tracking information of the user of your system who is performing the action.

Agreement ID Model:

Response Payload

Property	Type	Description
`AgreementUniqueReference`	string	The reference you provided to identify the agreement mirrored back to you.
`AgreementID`	string	Our unique ID of the agreement

HTTP Statuses - Agreement Create

202 (Accepted) - The request has been submitted for processing. Result will be provided via webhook.
400 (Bad Request) - Request didn’t pass validation check, or your business is not properly configured/enabled for processing PayTo Agreements.
409 (Conflict) - Duplicate request - there is already an agreement registered with the AgreementUniqueReference you provided.
500 (Internal Server Error) - An error occurred preventing the request from being processed.

Step 3 - Agreement Lookup

API

GET Agreement Lookup

Returns the full details, including the current status, of the agreement with the given reference.

Refer to Agreement Search Model for more information

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/agreements/{agreement-reference}

Example Response

JSON

{
    "business": {
        "businessId": "90129",
        "businessName": "worldpayforplatforms TEST"
    },
    "payer": {
        "payerId": "135032",
        "uniqueReference": "PayToPayerTest1",
        "groupReference": "PayToPayerTest1",
        "familyOrBusinessName": "Smith",
        "givenName": "Bob",
        "address": null,
        "email": null,
        "phone": null,
        "mobile": null
    },
    "agreementID": "505f58f8-1ad8-4648-aba2-088d1efa0510",
    "agreementStatus": "ACTIVE",
    "agreementUniqueReference": "PayToPayerAgreementTest1",
    "payerUniqueReference": "PayToPayerTest1",
    "payerName": "Bob Smith",
    "payerIsBusiness": false,
    "description": "This is an example for PayTo description",
    "agreementPurpose": "OTHR",
    "payIDType": "EMAL",
    "payID": "test@test.com",
    "paymentAmountType": "VARI",
    "paymentAmount": null,
    "paymentAmountMax": 1000.00,
    "paymentAmountFirst": 10.00,
    "paymentAmountLast": 10.00,
    "validFromDate": "2024-07-09T00:00:00",
    "validToDate": null,
    "frequencyType": "ADHO",
    "allowAutomaticExtension": true,
    "isAttended": false,
    "actionRequestedByTime": "2024-07-30T10:00:00+10:00",
    "createdTime": "2024-07-08T09:39:58.41+10:00",
    "lastUpdateTime": "2024-07-08T09:45:27.8+10:00"
}

Agreement Search Model

Property	Type	Description
`Business`	model: Business Info	Info of the business the payment is attached to.
`Payer`	model: Payer Info	Info of the payer the payment is attached to.
`Time`	DateTime	Date/time when payment was originally submitted for processing.
`Reference`	string	The unique reference you provided when you submitted the payment.
`AgreementUniqueReference`	string	The unique reference of the agreement the payment is attached to.
`PaymentID`	string	Our unique payment ID/reference.
`AgreementID`	string	Our unique agreement ID/reference.
`Amount`	decimal	The amount of the transaction that has been processed by the bank.
`AmountRequested`	decimal	The transaction amount you initially specified to be processed (this will match the `Amount` parameter above unless payer-paid fees were added to the transaction).
`StatusCode`	enum: Transaction status model	Code of the current status of the transaction.
`SubStatusCode`	enum: Transaction Sub-Status model	Secondary code for the current status of the transaction that can provide more information on that particular status (only some types of transactions will have a sub status).
`LastUpdateTime`	DateTime	Date/time on which the last status update on this payment was processed.

HTTP Statuses - Agreement Lookup

200 (OK) - The agreement was found and returned as the payload.
400 (Bad Request) - Request didn’t pass validation check, or your business is not properly configured/enabled for processing PayTo Agreements.
404 (Not Found) - No existing agreement with the agreement reference provided was found.
500 (Internal Server Error) - An error occurred preventing the request from being processed.

Step 4 - Payment submit

API

POST Payment Submit

This endpoint will submit a new PayTo Payment for an existing agreement. The processing of the new payment is performed asynchronously - you will need subscribe to our PayTo Payment event webhooks to be notified of the result of the transaction.

Note that the agreement must be in the ACTIVE status for payments to be able to be processed for it.

Refer to PayTo Payment Model and PayTo Payment ID model below for more information

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/agreements/{agreement-reference}/payments

JSON

{
    "Reference": "PayToPaymentTestReference1",
    "Amount": 100.00,
        "Audit": {
      "Username": "Example-User",
      "UserIP": "1.2.3.4"
    }
  }

Example Response

JSON

{
    "reference": "PayToPaymentTestReference1",
    "transactionID": "PTP_39"
}

PayTo Payment Model

Property	Type	Description
`Reference`	string (100)	Unique reference you provide to identify the transaction (must be unique across all your transactions of all types).
`Amount`	decimal	Amount of the transaction (include decimal point for currencies with cents).
`Audit`	model: Audit	Can be used to provide tracking information of the user of your system who is performing the action.

PayTo Payment ID Model

Property	Type	Description
`Reference`	string	The reference you provided mirrored back to you.
`TransactionID`	string	Our unique transaction ID.

HTTP Statuses - Payment Submit

202 (Accepted) - The request has been submitted for processing. Result will be provided via webhook.
400 (Bad Request) - Request didn’t pass validation check, the agreement is not in the ACTIVE status, or your business is not properly configured/enabled for processing PayTo Agreements.
404 (Not Found) - No existing agreement with the agreement reference provided was found.
409 (Conflict) - Duplicate request - there is already an transaction registered with the Reference you provided.
500 (Internal Server Error) - An error occurred preventing the request from being processed.

Step 5 - Payment Lookup

API

GET Payment Lookup

Returns the full details, including the current status, of the PayTo Payment with the given reference. Only payments processed within the last 6 months can be looked up using this method - use Transaction Search for older payments.

When a PayTo payment is submitted the transaction status will either be:
- 'P' (Pending = pending response from account holders bank)
- ‘C’ (Cleared = Successful)
- 'R' (Rejected - Failed transaction)
  - If a transaction is rejected with a decline reason supplied by the issuer we will return this response. Refer to Transaction Sub-Status Code.
On the 2nd business day, the statuscode will change to 'S' when the funds have been settled.

Refer to Agreement Payment Search Model for more information

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/agreements/payments/{payment-reference}

Example Response

JSON

{
    "business": {
        "businessId": "90129",
        "businessName": "worldpayforplatforms TEST"
    },
    "payer": {
        "payerId": "135032",
        "uniqueReference": "PayToPayerTest1",
        "groupReference": "PayToPayerTest1",
        "familyOrBusinessName": "Citizen",
        "givenName": "Jane",
        "address": null,
        "email": null,
        "phone": null,
        "mobile": null
    },
    "time": "2024-07-08T12:44:15.33+10:00",
    "reference": "PayToPaymentTestReference1",
    "agreementUniqueReference": "PayToAgreementTest1",
    "paymentID": "PTP_39",
    "agreementID": "505f58f8-1ad8-4648-aba2-088d1efa0510",
    "amount": 100.00,
    "amountRequested": 100.00,
    "statusCode": "C",
    "subStatusCode": 0,
    "lastUpdateTime": "2024-07-08T12:44:15.34+10:00"
}

Agreement Payment Search Model

Property	Type	Description
`Business`	model: Business Info	Info of the business the payment is attached to.
`Payer`	model: Payer Info	Info of the payer the payment is attached to.
`Time`	DateTime	Date/time when payment was originally submitted for processing.
`Reference`	string	The unique reference you provided when you submitted the payment.
`AgreementUniqueReference`	string	The unique reference of the agreement the payment is attached to.
`PaymentID`	string	Our unique payment ID/reference.
`AgreementID`	string	Our unique agreement ID/reference.
`Amount`	decimal	The amount of the transaction that has been processed by the bank.
`AmountRequested`	decimal	The transaction amount you initially specified to be processed (this will match the `Amount` parameter above unless payer-paid fees were added to the transaction).
`StatusCode`	enum: Transaction status model	Code of the current status of the transaction.
`SubStatusCode`	enum: Transaction Sub-Status model	Secondary code for the current status of the transaction that can provide more information on that particular status (only some types of transactions will have a sub status).
`LastUpdateTime`	DateTime	Date/time on which the last status update on this payment was processed.

HTTP Statuses - Payment Lookup

200 (OK) - The payment was found and returned as the payload.
400 (Bad Request) - Request didn’t pass validation check, or your business is not properly configured/enabled for processing PayTo Agreements.
404 (Not Found) - No existing payment with the reference provided was found.
500 (Internal Server Error) - An error occurred preventing the request from being processed.

Step 6 - Agreement Status Update

API

PUT Agreement Status Update

Can be used to update the status of an existing agreement. The processing of the status change is performed asynchronously - you will need subscribe to our PayTo Agreement event webhooks to be notified as to whether or not the status change was successful.

Refer to Agreement Status Update Model for more information

If a PayTo Agreement is suspended the PayTo Agreement cannot be resumed by the business. It must be resumed by the account holder.

If a PayTo agreement is cancelled by the account holder, the PayTo agreement cannot be re-activated. A new PayTo agreement must be created and accepted by the accountholder.

Sample

Example Request

JSON

{{url}}/businesses/{{business-id}}/agreements/{agreement-reference}/status

JSON

{
    "ChangeToStatus": "SUSPEND",
        "ReasonDescription": "test suspension",
        "Audit": {
      "Username": "Example-User",
      "UserIP": "1.2.3.4"
    }
  }

Example Response

This request does not return any response body

Agreement Status Update Model

Property	Type	Description
`ChangeToStatus`	enum	The status that you want to change the agreement to. Allowed values: `CANCEL` - Cancel the agreement. `SUSPEND` - Suspend the agreement. `RESUME` - Reactivate a previously suspended agreement.
`ReasonDescription`	string - 128 max length (basic alphanumeric text only)	Can be used as a narrative to describe the reason for the status change.
`Audit`	model: Audit	Can be used to provide tracking information of the user of your system who is performing the action.

HTTP Statuses - Agreement Status Update

202 (Accepted) - The request has been submitted for processing. Result will be provided via webhook.
400 (Bad Request) - Request didn’t pass validation check, or your business is not properly configured/enabled for processing PayTo Agreements.
500 (Internal Server Error) - An error occurred preventing the request from being processed.

Step 7 - Setup Webhooks

To set up webhooks for testing and production the below will need to be setup:

Webhook Url: You provide us a single URL (must be https://) to which we will POST all our web messages for all event types.
Shared Secret:
- Production: This is a randomly generated 88-character string that is unique to your business which we will generate and provide to you.
- Sandbox: Our Integrations/Implementations team will provide the credentials to you for testing.

To prove a webhook is a legitimate and unaltered message that was sent by us, and is intended for you, we include a signature which must be validated using a shared secret.
When we send you a webhook we will look for a successful (2xx) HTTP Status response from your web app. If we receive it we will consider the webhook successfully delivered. If we receive a status other than 2xx, or if we are unable to connect to your webhook URL, we will attempt to deliver the webhook an additional 3 times using the following back-off frequency:
- 1st Retry - After 30 minutes.
- 2nd Retry - After 2 hours.
- 3rd Retry - After 24 hours.
Our webhook message can contain one of more data objects depending on the event type. The data provided in the webhook is the current status of that entity at the time the webhook is generated. In general, determining what change occurred can be deduced just from the EventType itself, with the data object(s) only needed to get the ID/Reference to match to the entity in your system.
In some situations (e.g. connection dropouts or timeouts), a webhook might be delivered to you multiple times. We provide a unique Message ID with each webhook which you can use for duplicate checking.
In some situations (e.g. if a webhook is unable to be delivered on first attempt), webhooks might be delivered out of sequence. For some event types, before actioning a webhook, it might be prudent to check the current status of the related entities in your system to make sure processing the webhook would not cause an invalid workflow. We provide timestamps with each webhook which can be useful for determining sequencing.

Webhook Messages

Our webhook messages are delivered with the following:

HTTP Headers

The following HTTP headers are included with each webhook:

x-payrix-id - A GUID providing a unique ID for identifying this particular webhook. This can be used for duplicate checking.
x-payrix-timestamp - Unix/Epoch time (milliseconds since 01/01/1970) for when the webhook was generated. Can be used for event sequencing.
x-payrix-signature - Base-64 encoded HMAC-SHA256 signature. This must be used to verify the legitimacy of the message by taking the entire POST body of the message and performing your own HMAC-SHA256 calculation using your shared secret and checking that the value you get matches the signature.

HTTP POST Body

The payload of the message is a JSON rendering of the Webhook Message Model described below.

Webhook Model

All our webhooks, for all event types, share a single overall data model. This model includes one or more sub-models depending on the types of entities that were affected by the event the webhook is reporting.

Webhook Message Model with the following fields:

Property	Type	Description
`Id`	string	A GUID providing a unique ID for identifying this particular webhook. This can be used for duplicate checking.
`EventTime`	DateTime	Date/time when the event triggering the webhook occurred.
`EventType`	enum	The event that occurred which the webhook is a notification of. Will be one of the following: npp_payto_agreement_active npp_payto_agreement_amended npp_payto_agreement_cancelled npp_payto_agreement_declined npp_payto_agreement_disputed npp_payto_agreement_error npp_payto_agreement_pending npp_payto_agreement_recalled npp_payto_agreement_resolution npp_payto_agreement_resumed npp_payto_agreement_suspended npp_payto_agreement_timeout npp_payto_payment_disputed npp_payto_payment_error npp_payto_payment_pending npp_payto_payment_rejected npp_payto_payment_resolution npp_payto_payment_successful npp_payto_payment_refunded
`Transaction`	model: Transaction Search	If the event relates to a particular transaction, the details of the transaction are provided here.
`Payer`	model: Payer Info	If the event relates to a particular payer, the details of the payer are provided here.
`Agreement`	model: PayTo Agreement Search	If the event relates to a particular PayTo Agreement, the details of the agreement are provided here.
`SentTime`	DateTime	Date/time when the webhook was first sent.
`Timestamp`	long integer	Unix/Epoch time (milliseconds since 01/01/1970) for when the webhook was generated. Can be used for event sequencing.

Testing Help Desk in Sandbox Portal

Action Agreement

Once an agreement has been created you can simulate PayTo Agreement Acceptance, Decline or Cancel by following the below steps:
1. Log in to Sandbox Portal
2. Once logged in, click on PayTo heading
3. Search for Agreement and Click View
5. Then click ‘Action Agreement’
6. Here you can use the ‘Sandbox Self-serve’ function to simulate responses to trigger agreement updates or change the status of the agreement and the sending of their associated webhooks.

Trigger successful or failed payment

Once a PayTo payment has been submitted, you can simulate a successful or failed payment result by following the below steps:
1. Log in to Sandbox Portal
2. Once logged in, click on PayTo heading
3. Search for Agreement and Click View
5. When you enter the agreement page, Click View in the ‘Payment History’ section
7. Once you enter the Payment Details page, scroll down and use the Sandbox Self-Serve and to trigger a successful or failed payment event.

You can use the PayTo Self-Serve function along with the standard ‘Self-Service Centre’ to run the settlement process once payments have been processed and successful/cleared.

This concludes the guide to implementing the PayTo Payments platform.