Delete hosted checkout
Hosted Checkouts
Using hostedCheckouts you can process transactions using MyCheckout, our easy to use hosted responsive payment pages. Your consumers will be able to complete the payment process using MyCheckout that is hosted by us. Using these pages to capture card details and process card transactions will greatly reduce not only your integration efforts, but it will also reduce your 'PCI exposure' to the lowest level (SAQ-A).
The layout and look and feel of the MyCheckout Pages can be managed through the Configuration Center. Here you will find the powerful, yet very intuitive MyCheckout editor that lets you create multiple variations of your hosted payment pages hosted by us. If you have created multiple versions you are able to direct your consumers to specific variants through this API. This allows you easily test out different variations or continue specific campaigns all the way through to the payment pages.
The MyCheckout pages automatically adapt based on screen width of your consumers device. Clients that do not support JavaScript to be run on the client will still be able to make payments (although they will lack all the client side validation and automatic formatting to assist them). Please note that both the responsive nature and the support for clients without JavaScript support might not apply to 3rd party payment pages that the consumer might be redirected to to complete the payment.
MyCheckout is also modular in its setup, allowing you to specify exactly what you want us to do as part of your checkout flow. You decide if we should display the payment product selection and/or the confirmation page after a successful payment.
In case a payment product that requires the consumer to (manually) push the funds was selected, you will have the option to show these instructions again at a later moment. You could show them on your website in an area where the consumer can track the progress of their order. To avoid multiple payments you should however avoid showing them again for transactions that have already been paid.
Request
You can invalidate a hosted checkout session by doing a delete on the hostedCheckoutId. When the session has been invalidated, you will no longer be able to retrieve details of the hosted checkout session with a get request. The request does not have any additional input parameters.
Request example
This scenario you will probably use the most
-
const sdkResponse = await client.v1.hostedcheckouts.remove("merchantId", "hostedCheckoutId"); // sdkResponse has the following properties: // - status: the HTTP status code // - body: the response body // - isSuccess: true if the call was successful, // or false if the Worldline Global Collect platform returned an error response
Responses
Please find below an overview of the possible responses.
Response 204 - No content
The hosted checkout was successfully removed.
Response 404 - Not foundErrorResponse
A hosted checkout with the provided id was not found.
|
Properties
|
|||
| Property | Type | Required | Details |
|---|---|---|---|
| errorId | string | yes | read close |
|
close
DescriptionUnique reference, for debugging purposes, of this error response
|
|||
| array of object | yes | read close | |
|
close
DescriptionList of one or more errors
|
|||
| object | no | read close | |
| category | string | no | read close |
|
close
DescriptionCategory the error belongs to. The category should give an indication of the type of error you are dealing with.
Possible values:
|
|||
| code | string | yes | read close |
|
close
DescriptionError code
|
|||
| httpStatusCode | integer | no | read close |
|
close
DescriptionHTTP status code for this error that can be used to determine the type of error
|
|||
| id | string | no | read close |
|
close
DescriptionID of the error. This is a short human-readable message that briefly describes the error.
|
|||
| message | string | no | read close |
|
close
DescriptionHuman-readable error message that is not meant to be relayed to customer as it might tip off people who are trying to commit fraud
|
|||
| propertyName | string | no | read close |
|
close
DescriptionReturned only if the error relates to a value that was missing or incorrect.
Contains a location path to the value as a JSonata query. Some common examples:
|
|||
| requestId | string | no | read close |
|
close
DescriptionID of the request that can be used for debugging purposes
|
|||
Response example
This scenario you will probably use the most
-
{ "errorId" : "657b10da-d2f9-4088-a948-bf190ef516b1-00000318", "errors" : [ { "code" : "1010", "message" : "UNKNOWN_HOSTED_CHECKOUT_ID" } ] }