To start to use this component, please install the "GOV UK Pay Service" application in your factory.
It's provided an integration to manage payments, refunds, and agreements and to search by existing disputes.
The authentication/authorization of each request is made by sending the API key of your service account into the HTTP request "Authorization" header.
The authorisation header is your service account API Key. You must include an authorisation header.
When you have the API Key, add it to a header as follows: "Authorization": "Bearer {YOUR_API_KEY}".
In the "OnBeforeRequest" of the consumed REST API, a server action wrapper "OnBeforeRequest_GovUKPayAPI" is called:This wrapper manipulates the HTTP Request before it is sent, with the main goal of gathering the API Key from the header request and appending it defined as a value of the "Authorization" HTTP request header.
However, if you are authorising a payment (i.e. sending card details to authorise a Mail Order/Telephone Order (MOTO) payment) the authentication does not need an API bearer token, because the request is instead secured with the one_time_token you received when you created the payment.
To authorise a MOTO payment, you need to set the "authorisation_mode" as "moto_api" when you are creating the payment.
You can use this endpoint to authorise payments you have created with the authorisation_mode set to moto_api.
This endpoint does not need an API bearer token. The request is instead secured with the one_time_token you received when you created this payment.
You can also read more about sending card details through our API in our task-based guidance.This service action includes the flow needed to send card details to authorize a MOTO payment request.
Below are presented the required and optional request fields for this integration and also its definitions:
The full card number from the paying user’s card.
The name on the paying user’s card.
The card verification code (CVC) or card verification value (CVV) on the paying user’s card.
The expiry date of the card the user paid with.
This value must be in MM/YY format.
A single-use token that identifies the payment to authorise and authenticates this request.
GOV.UK Pay returns a one_time_token when you create a payment with the authorisation_mode set to moto_api.
You can read more about creating and authorising MOTO payments by sending card details through the API.
To use this integration you can create a server action wrapper, i.e. "AuthorizeMOTOPaymentWrapper", that will call the service action "Authorize_MOTOPayment" from GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Createapayment" method is done through the service action "Create_Payment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to create a new payment.
You can also read more about the end-to-end process of taking payments using GOV.UK Pay in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the create a payment request.
Additionally, the "Request" input parameter is converted to the required structure of the "Createapayment" API method, and the integration response is converted to a local "Response" structure.
To get an API key, sign in to GOV.UK Pay and go to the Settings page.
The value of the API Key is then sent in the "Authorization" header of the request.To see more details about the Authorization Header, please click here.
Idempotency in an API is when multiple identical requests have the same effect as making a single request. In GOV.UK Pay, you can avoid double-charging users by using the Idempotency-Key header to make your API requests idempotent when taking recurring payments.
Use this header when creating a recurring payment to make your request idempotent.
Idempotency is useful if you create a recurring payment through our API but do not receive a response due to network failure. In this situation:
Sets the amount the user will pay, in pence.
The maximum value is 10000000 (£100,000) if your PSP is Stripe.
The maximum value is 500000 (£5,000) if your PSP is Worldpay.
Sets how you intend to authorise the payment.
Payments created with web mode follow the standard GOV.UK Pay payment journey. Paying users visit the next_url in the response to complete their payment.
web
next_url
Payments created with agreement mode are authorised with an agreement for recurring payments. If you create an agreement payment, you must also send an active agreement_id. You must not send return_url, email, or prefilled_cardholder_details or your request will fail.
agreement
agreement_id
return_url
email
prefilled_cardholder_details
Payments created with moto_api mode return an auth_url_post object and a one_time_token. You can use auth_url_post and one_time_token to send the paying user’s card details through the API and complete the payment.
moto_api
auth_url_post
one_time_token
If you create a moto_api payment, do not send a return_url in your request.
Available values are:
web - default
You can use this parameter to delay taking a payment from the paying user’s bank account. For example, you might want to do your anti-fraud checks on payments or check that users are eligible for your service.
Defaults to false.
false
A human-readable description of the payment you’re creating. Paying users see this description on the payment pages. Service staff see the description in the GOV.UK Pay admin tool.
Limited to 255 characters and should not contain URLs.
Prefills the paying user’s email address field when they make their payment.
Limited to 254 characters.
You can read more about prefilling fields on the Enter card details page.
Sets the language of the user’s payment page.Available values are:
en
cy
An object that adds custom metadata to a payment using parameter key-value pairs.
The metadata object must contain between 1 and 10 parameter keys.
metadata
Parameter keys are limited to 30 characters. Parameter values are limited to 100 characters. Parameter values can be empty.
You cannot add or change metadata keys or values after you’ve created the payment.
You can use this parameter to designate a payment as a Mail Order / Telephone Order (MOTO) payment.
moto defaults to false if you do not include it in your request.
moto
You must have MOTO payments enabled on your GOV.UK Pay account to use the moto parameter.
You can read more about enabling taking payments over the phone.
An object that prefills the paying user’s address and cardholder name fields when they make their payment.
prefilled_cardholder_details can contain 2 optional parameters:
cardholder_name
cardholder_namebilling_address
Prefills the paying user’s cardholder name field when they make their payment.
Limited to 255 characters.
An object that prefills the paying user’s billing address.
If the country value is invalid or missing, the Country/territory field on the user’s payment page defaults to the United Kingdom.
country
billing_address can contain:
billing_address
line1
line2
postcode
city
Associate a reference with this payment.
reference is not unique - multiple payments can have identical reference values.
reference
Limited to 255 characters and must not contain URLs.
The URL the paying user is directed to after their payment journey on GOV.UK Pay ends.
Limited to 2,000 characters and must not be JSON-encoded.
You can read more about choosing your return URL and matching paying users to payments.
Use this parameter to set up an existing agreement for recurring payments.
The set_up_agreement value you send must be a valid agreement_id.
set_up_agreement
agreement_id.
Read more about taking recurring payments.
To use this integration you can create a server action wrapper, i.e. "CreatePaymentWrapper", that will call the service action "Create_Payment" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
An integration with the "Cancelapayment" method is done through the service action "Cancel_Payment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to cancel a payment.
You can also read more about how cancelling payments fits into the process of taking a payment in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the cancel a payment request.
The ID of the payment you’re cancelling is mapped with the argument payment_id from the REST API.
GOV.UK Pay associates a unique paymentId with a payment when you create that payment.
paymentId
To use this integration you can create a server action wrapper, i.e. "CancelPaymentWrapper ", that will call the service action "Cancel_Payment " from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
An integration with the "Captureapayment " method is done through the service action "Capture_Payment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to take (‘capture’) a delayed payment from the paying user’s bank account.
You can also read more about setting up and creating delayed payments, as well as possible use cases for delaying payments, in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the capture a payment request.
The ID of the payment you’re capturing is mapped with the argument payment_id from the REST API.
To use this integration you can create a server action wrapper, i.e. "CapturePaymentWrapper", that will call the service action "Capture_Payment" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
An integration with the "Getapayment" method is done through the service action "Get_Payment" implemented in the GOVUK_Pay_ISmodule.
You can use this endpoint to get details about a single payment you’ve previously created.
You can also read more about the GOV.UK Pay reporting process in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the get a single payment request.
Additionally, the "Getapayment" API method response is converted to a local "Response" structure.
Returns the payment with the matching payment_id.
payment_id
GOV.UK Pay associates a unique payment_id with a payment when you create that payment.
To use this integration you can create a server action wrapper, i.e. "GetPaymentWrapper", that will call the service action "Get_Payment" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
An integration with the "Geteventsforapayment" method is done through the service action "Get_EventsForPayment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to get a list of a payment’s events.
A payment event is when the payment’s state changes, such as when the payment is created, or when the paying user submits their details.
state
You can also read more about how getting a payment’s events fits into the GOV.UK Pay reporting process in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the get events for a payment request.
Additionally, the "Geteventsforapayment" API method response is converted to a local "Response" structure.
The unique ID of the payment you want a list of events for.
To use this integration you can create a server action wrapper, i.e. "GetPaymentEventsWrapper", that will call the service action "Get_EventsForPayment" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.
An integration with the "Searchpayments" method is done through the service action "Search_Payments" implemented in the GOVUK_Pay_ISmodule.
You can use this endpoint to search for payments you’ve previously created. The payments are sorted by date, with the most recently created payments appearing first.
The payments are sorted by date, with the most recently created payments appearing first.
You can also read more about how searching for payments fits into the GOV.UK Pay reconciliation process in our task-based guidance.
Additionally, the FromDate, ToDate, FromSettledDate and ToSettledDate are converted to ISO 8601 format, and the integration response is converted to a local "Response" structure.
FromDate
ToDate
FromSettledDate
ToSettledDate
Returns payments with reference values exactly matching your specified value.
This parameter is not case-sensitive.
A reference was associated with the payment when that payment was created.
Returns payments with matching email values. You can use full or partial email addresses.
The email value is the paying user’s email address. It was entered either by the service when the payment was created or by the paying user when they completed their payment.
You can read more about prefilling payment fields.
Returns payments in a matching state.
state reflects where a payment is in the payment status lifecycle. You can read more about the payment status lifecycle and the meaning of different state values.
Available state values are:
created
started
submitted
capturable
success
failed
cancelled
error
Returns payments paid with a particular card brand.
Available card_brand values are:
card_brand
american-express
diners-club
discover
jcb
maestro
master-card
unionpay
visa
Returns payments created on or after the from_date.
from_date
Date and time must be coordinated in Universal Time (UTC) and ISO 8601 format to second-level accuracy - YYYY-MM-DDThh:mm:ssZ.
YYYY-MM-DDThh:mm:ssZ
Returns payments created before the to_date.
to_date
Returns payments settled on or after the from_settled_date value.
from_settled_date
You can only search by settled date if your payment service provider is Stripe.
Date must be in ISO 8601 format to date-level accuracy - YYYY-MM-DDThh:mm:ssZ.
Payments are settled when your payment service provider sends funds to your bank account.
Returns payments settled before the to_settled_date value.
_settled_date
Returns a specific page of results.
Defaults to 1.
1
You can read more about search pagination.
The number of payments returned per results page.
Defaults to 500. The maximum value is 500.
500
Returns payments paid with cards under this cardholder's name.
Returns payments paid by cards beginning with the first_digits_card_number value.
first_digits_card_number
first_digits_card_number value must be 6 digits.
Returns payments paid by cards ending with the last_digits_card_number value.
last_digits_card_number
last_digits_card_number value must be 4 digits.
Returns payments that were authorised using the agreement with this agreement_id.
Must be an exact match.
To use this integration you can create a server action wrapper, i.e. "SearchPaymentsWrapper", that will call the service action "Search_Payments" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
As the above examples don't have all fields from the response, please check the expected full response from the API here.
An integration with the "Createanagreement" method is done through the service action "Create_Agreement" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to create a new agreement.
An agreement represents an understanding between you and your paying user that you’ll use their card to make ongoing payments for a service.
You can also read more about the end-to-end process of taking recurring payments using GOV.UK Pay in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the create an agreement request.
Additionally, the "Createanagreement" API method response is converted to a local "Response" structure.
A human-readable description of the purpose of the agreement for recurring payments.
We’ll show the description to your user when they make their first payment to activate this agreement.
description
Associate a reference with this agreement to help you identify it.
Associate an identifier with the user who will enter into this agreement with your service.
user_identifier is not unique – multiple agreements can have identical user_identifier values.
user_identifier
You should not include personal data in user_identifier.
To use this integration you can create a server action wrapper, i.e. "CreateAgreementWrapper", that will call the service action "Create_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Cancelanagreement" method is done through the service action "Cancel_Agreement" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to cancel a recurring payments agreement in the active status. Read more about agreement status values.
active
status
You cannot use a cancelled agreement to take recurring payments. Reactivate a cancelled agreement by taking a payment from the user and telling the GOV.UK Pay API to save the user’s card details.
You can also read more about the end-to-end process of taking recurring payments using GOV.UK Pay in our task-based guidance.This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the cancel an agreement request.
The ID of the agreement you’re cancelling is mapped with the argument agreement_id from the REST API.
GOV.UK Pay associates a unique agreement_id with an agreement when you create that agreement.
To use this integration you can create a server action wrapper, i.e. "CancelAgreementWrapper", that will call the service action "Cancel_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Getanagreement" method is done through the service action "Get_Agreement" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to get information about a single recurring payments agreement.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the get an agreement request.
Additionally, the "Getanagreement" API method response is converted to a local "Response" structure.
Returns the agreement with the matching agreement_id.
GOV.UK Pay generated an agreement_id when you created the agreement.
To use this integration you can create a server action wrapper, i.e. "GetAgreementWrapper", that will call the service action "Get_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Searchagreements" method is done through the service action "Search_Agreements" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to search for recurring payments agreements. The agreements are sorted by date, with the most recently created agreements appearing first.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the search agreements request.
Additionally, the "Searchagreements" API method response is converted to a local "Response" structure.
Returns agreements with a reference that exactly matches the value you sent.
A reference was associated with the agreement when that agreement was created.
Returns agreements in a matching status.
status reflects where an agreement is in its lifecycle.
You can read more about the meanings of the different agreement status values.
Available status values are:
The number of agreements returned per results page.
To use this integration you can create a server action wrapper, i.e. "SearchAgreementsWrapper", that will call the service action "Search_Agreements" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Submitarefundforapayment" method is done through the service action "Submit_RefundForPayment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to refund a payment.
The payment must be refundable for this request to work.
You can also read more about the GOV.UK Pay refund process in our task-based guidance.This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the submit a refund for payment request.
The ID of the payment you’re refunding.
The amount you want to refund to your user in pence.
The amount available to refund before submitting this request.
refund_amount_available must match the amount_available you receive when you check if you can refund a payment. Use GET /v1/payments/{PAYMENT_ID} to check if you can refund this payment.
refund_amount_available
amount_available
GET /v1/payments/{PAYMENT_ID}
To use this integration you can create a server action wrapper, i.e. "SubmitRefundForPaymentWrapper", that will call the service action "Submit_RefundForPayment" from GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Getapaymentrefund" method is done through the service action "Get_PaymentRefund" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to get details about an individual refund.
You can also read more about the GOV.UK Pay refund process in our task-based guidance.This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the check the status of a refund request.
The unique ID of the payment you want to view a refund of.
The unique ID of the refund you want to view.
GOV.UK Pay associates a unique refund_id with a refund when you refund a payment.
refund_id
If one payment has multiple refunds, each refund has a different refund_id.
To use this integration you can create a server action wrapper, i.e. "SearchPaymentRefundWrapper", that will call the service action "Get_PaymentRefund" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Getallrefundsforapayment" method is done through the service action "Get_RefundsForPayment" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to search for refunds you’ve previously created. The refunds are sorted by date, with the most recently created refunds appearing first.
You can also read more about the GOV.UK Pay refund process in our task-based guidance.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the get all refunds for a payment request.
Additionally, the "Getallrefundsforapayment" API method response is converted to a local "Response" structure.
The unique ID of the payment you want a list of refunds for.
To use this integration you can create a server action wrapper, i.e. "GetRefundsForPaymentWrapper", that will call the service action "Get_RefundsForPayment" from GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the search for payment refunds request.
Returns refunds created on or after the from_date.
Returns refunds created before the to_date.
Returns refunds settled on or after the from_settled_date.
You can only use from_settled_date if your payment service provider is Stripe.
Refunds are settled when Stripe takes the refund from your account balance.
Returns refunds settled before the to_settled_date.
You can only use to_settled_date if your payment service provider is Stripe.
The number of disputes returned per results page.
To use this integration you can create a server action wrapper, i.e. "SearchRefundsWrapper", that will call the service action "Search_Refunds" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.If your application needs to present the response on the screen, please check the following example or use this test page:
An integration with the "Searchdisputes" method is done through the service action "Search_Disputes" implemented in the GOVUK_Pay_IS module.
You can use this endpoint to search disputes.
A dispute is when a paying user challenges a completed payment through their bank.
This service action includes the flow needed to validate the required field APIKey, through a "CheckRequest" server action wrapper, and to send the search disputes request.
Returns disputes raised on or after the from_date.
Returns disputes raised before the to_date.
Returns disputes settled on or after the from_settled_date.
Disputes are settled when your payment service provider takes the disputed amount from a payout to your bank account.
You can only use from_settled_date to find disputes raised on or after 8 August 2022.
Returns disputes settled before the to_settled_date.
You can only use to_settled_date to find disputes raised on or after 8 August 2022.
Returns disputes with a matching status.
status reflects what stage of the dispute process a dispute is at.
You can read more about the meanings of different status values.
needs_response
won
lost
under_review
To use this integration you can create a server action wrapper, i.e. "SearchDisputesWrapper", that will call the service action "Search_Disputes" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration.Please check the expected full response from the API here.
The callback authorization is checked in the "OnAuthentication" event of each callback exposed REST API by validating the hexadecimal hash-based message authentication code (HMAC) of the webhook message body, generated using the SHA-256 algorithm, with the value sent through the Pay-Signature HTTP Request header. In the "OnAuthentication" is called a server action wrapper "ValidateCallbackAuthorization" that will validate the bearer token for the authorization.
Pay-Signature
A server action wrapper "CheckAuthorization" is called which will validate if the Pay-Signature request header value is the same as the webhook message body after being computed with the "HMACSHA256" algorithm and signed with the webhook signing secret.
To view your webhook’s signing secret, select Manage signing secret from the Manage webhook page in the GOV.UK Pay admin tool.
Below are the steps executed within the "CheckAuthorization" server action wrapper to verify if the request is, or not is, authorized:
An exposed REST API method "UpdatePayment" is available through the endpoint WebhookMessages whose main goal is to update a payment status through the received request. request.This callback API only should be used/set up through GOV.UK Pay if you are using the service actions available in the GovUK_Pay_CS to store the information of the payment created.
Below are presented the request fields for this API and its definitions:
The unique identifier of this webhook message.
The version of this API.
When the payment event happened and activated the webhook.
This value uses Coordinated Universal Time (UTC) and ISO 8601 format - YYYY-MM-DDThh:mm:ssZ
The unique ID that GOV.UK Pay is automatically generated for the payment or refund.
When the resource is a payment, resource_id is identical to the payment_id. When the resource is a refund, resource_id is identical to the refund_id.
resource_id
Indicates whether the resource is a payment or a refund.
resource
resource_type is one of the following:
resource_type
payment
refund
The event that activated the webhook. This value will be one of the events you selected when you created the webhook.
Possible values are:
card_payment_succeeded
card_payment_captured
card_payment_settled
card_payment_refunded
Contains details of the payment or refund that has activated the webhook.
Attributes in resource are the same as you get when finding a payment in the GOV.UK Pay API.
You can read about the attributes in the resource object on our reference page for getting information about a payment.
This API receives a request that will be serialized to JSON and its binary is stored as a record in the PaymentToProcess database entity. If the request is successful, the status code of the response is 200.
200
If you don't want to process the request, a site property DisableSavingPayment is available whose value "true" allows you to send the status code 200 in the response without the request having been sent for processing.
To ensure that each request is secure and only authorized requests are allowed, and processed, a check is made whether the hexadecimal hash-based message authentication code (HMAC) of the body request is the same as the HMAC sent in the Pay-Signature HTTP request header.
Being exposed to process events, when a record is created in the PaymentToProcess database entity, a light process execution activity UpdatePaymentActivity is automatically triggered.
Before processing the payment status update begins, it's validated that the record actually exists in the PaymentToProcess entity and its request content is not empty. If any of the sentences fail, the process ends.
Once a binary request is obtained from the PaymentToProcess entity, it's converted to JSON so that it can be deserialized into the correct structure and sent to the "ProcessingUpdatePaymentActivity" wrapper so that it can be processed.
This wrapper verifies if the payment to process exists in the database, using the service action "Get_PaymentByPaymentId" of the GovUK_Pay_CS module (i.e. if a local payment is related to the "payment_id" of the Gov.UK Pay API).
If a local payment exists, then it is verified if an event with the same resource_id, event_type and created_date is not available locally, using the "Get_PaymentWebhookEventByResourceId" service action of the GovUK_Pay_CS module.
If the message does not yet exist, the status of the local payment record is updated and the webhook event is created locally:
In the end, if the payment status update refers to a partial or full refund, we store the information for that refund locally, such as the amount still available for refund, the refund amount already submitted and the respective refund status:
available
full
pending
unavailable
If your application needs to save locally the new payment's status from the REST API, we provide core actions for this purpose, which are availablein the GovUK_Pay_CS module:
To get multiple payments or a single payment, saved locally, the service actions "Get_Payments" and "Get_PaymentById" of the GovUK_Pay_CS module are provided for this purpose.
To use this integration you can create a server action wrapper, i.e. "CreateAgreementWrapper", that will call the service action "Create_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration. If your application needs to present the response on the screen, please check the following example or use this test page:
In the "OnBeforeRequest" of the consumed REST API, a server action wrapper "OnBeforeRequest_GovUKPayAPI" is called: This wrapper manipulates the HTTP Request before it is sent, with the main goal of gathering the API Key from the header request and appending it defined as a value of the "Authorization" HTTP request header.
To use this integration you can create a server action wrapper, i.e. "SearchPaymentsWrapper", that will call the service action "Search_Payments" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration. If your application needs to present the response on the screen, please check the following example or use this test page:
To use this integration you can create a server action wrapper, i.e. "CancelAgreementWrapper", that will call the service action "Cancel_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration. If your application needs to present the response on the screen, please check the following example or use this test page:
To use this integration you can create a server action wrapper, i.e. "GetAgreementWrapper", that will call the service action "Get_Agreement" from the GovUK_Pay_IS module, passing the information required, and optional if needed, avoiding misbehaviour of this integration. If your application needs to present the response on the screen, please check the following example or use this test page:
An exposed REST API method "UpdatePayment" is available through the endpoint WebhookMessages whose main goal is to update a payment status through the received request. request. This callback API only should be used/set up through GOV.UK Pay if you are using the service actions available in the GovUK_Pay_CS to store the information of the payment created.