> For the complete documentation index, see [llms.txt](https://docs.saferpay.com/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.saferpay.com/home/integration-guide/testing-and-go-live.md). # Testing Saferpay offers an extensive Sandbox that allows you to simulate transactions, flows, and other things like Mail Phone Order or the [Secure PayGate](/home/interfaces/backoffice/secure-paygate.md). When integrating Saferpay, it is very beneficial to create your own test account. You can [get your own test account over here](https://test.saferpay.com). Everything you need will be sent to you via e-mail, including things like your test CustomerId, TerminalIds, the login for the Saferpay Test Backoffice, API user and password, etc. **Difference between the Test and Live environments** * First and foremost, test and live are completely separated systems. So everything you do on one or the other cannot be transferred to the other system, like your transactions or your saved cards. Due to this, it is very important that you also separate your data accordingly and keep an eye on which system the data belongs to. If actions are performed with data that does not belong to the respective system, the action will fail. This is so merchants may not confuse one system with the other. For example, by running on the test environment whilst thinking they're live. * To reinforce this philosophy, Saferpay will not accept real credit cards on the test environment and vice versa! The test environment uses especially designed test cards, which can be found further down on this page, alongside information about the simulators. * Furthermore, the test environment only runs simulators that will emulate the behavior of the given payment method. However, no real money will be transferred, of course. * The test environment will behave as closely to the live environment as possible - aside the above-mentioned differences -. To ensure this, every function and every URL is mirrored onto the test environment. For example, the live Backoffice can be found under , whereas the test Backoffice can be found under . You can access any URL by simply changing the **www** to **test** and vice versa. This also applies to API URLs. For example, `https://test.saferpay.com/api/Payment/v1/PaymentPage/Initialize` and `https://www.saferpay.com/api/Payment/v1/PaymentPage/Initialize`. The JSON object structure is the same on both systems, making a switch as easy as possible. ## Simulators and Test cards Saferpay offers an array of simulators and also connections to certain sandboxes. In this chapter, you will find all the information you need in order to test and, if needed, activate your desired payment method for testing. These simulators are either controlled directly via UI, the card number (PAN, if applicable), and/or the submitted amount. Please see the following details for the given payment method, on how to trigger specific test-cases. {% hint style="danger" %} These test payment means only work on the Saferpay Test environment and not on any live account/the production environment. On production, you must use your own real payment means, like a credit card. {% endhint %} {% hint style="warning" %} While we generally aim to make the simulators as intuitive as possible: They are simulators! Not all test cases may be available, or may be triggered the way you'd expect. All Saferpay Simulators do not connect to real systems (especially important in cases where a third party is simulated) and thus do not perform end-to-end tests. However, Saferpay does offer the possibility to connect towards sandboxes if a third-party provider offers such an environment. Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) for information on the availability and how to connect towards a sandbox. {% endhint %} {% hint style="info" %} If you have questions, problems, or other inquiries about testing, please [contact the Integration Support](/home/integration-guide/support.md#integration-support) for help. {% endhint %} ### Account-to-Account Payments Saferpay offers an A2A simulator that is controlled via the amount and has the following values: #### Authorization | Amount | Test case | | ------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | 40300tt | Simulates a PENDING authorization that lasts tt seconds and then results in a **successful** transaction. | | 40400tt | Simulates a PENDING authorization that lasts tt seconds and then results in a **declined** transaction. | | 4120000 | Authorization declined | | 4220000 | Authorization expired | | 4320000 | Authorization cancelled | #### Refund | Amount | Test Case | | ------- | ---------------------------- | | 7120000 | The refund will be declined. | {% hint style="info" %} Any other amount may result in a general success. {% endhint %} {% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test Account-to-Account Payments. {% endhint %} ### Alipay
AmountTest Case
AmountTest Case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined Refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test Alipay. {% endhint %} ### American Express It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: | Card Number | Test Case | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9070003150000008 |

Frictionless Y. Card simulates a fully successful frictionless flow.
Liability shift: YES, Authenticated: true

| | 9070003750000002 |

LiabilityShift can't be granted due to technical reasons. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: N/A

| | 9070004950000008 |

Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true

| | 9070004250000005 |

Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false

| | 9070004350000004 |

Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case.
Liability shift: N/A, Authenticated: N/A

| | 9070004150000006 |

3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift. Card goes through a challanged flow beforehand.
Liability shift: false, Authenticated: false

| | 9070103204160004 | Card to simulate a [Soft Decline](/home/integration-guide/general-information/psd2.md#non-compliance). **This card will ALWAYS return a Soft Decline, even if SCA was performed.** | ### Apple Pay Saferpay does offer an extensive Apple Pay simulator. All test cases are controlled through the simulator UI. Unlike production, you do not need an Apple device or browser to test Apple Pay! Please refer to the [Activation section](/home/integration-guide/payment-methods/applepay.md#activation) to see how to activate Apple Pay on the test environment. {% hint style="warning" %} Note that the server-to-server method does not use the Saferpay simulator, but instead needs special test cards provided by Apple, [which you can find over here](https://developer.apple.com/apple-pay/sandbox-testing/). **Please note: Only the Mastercard PANs are supported at this point.** {% endhint %} ### Bancontact It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: {% hint style="info" %} Bancontact uses an authentication procedure similar to [3D Secure](/home/integration-guide/general-information/3d-secure.md) with VISA and MasterCard. However, the difference is that Bancontact will automatically refuse all payments that aren't fully authenticated. Due to this, there are only these few outcomes possible. {% endhint %} | Card Number | Test case | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9110803150000003 |

Frictionless Card "enrolled".


Liability shift: YES

| | 9110803350000001 |

"Authentication failed". The card holder failed to authenticate him/herself.

Important: In this case, the authorization will fail.

| | 9110804950000003 |

Challenge Card "enrolled". This card is subjected to the full 3D Secure authentication process!


Liability shift: YES

| ### blik
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined Refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test blik. {% endhint %} ### Boncard | Card Number | Test case | | ----------------------------------- | ---------------- | | Success | 6299120000000011 | | Generic Decline | 6299120000000201 | | Card expired | 6299120000000235 | | Card unknown | 6299120000000243 | | Card locked | 6299120000000250 | | No funds | 6299120000000268 | | Card for simulating a failed refund | 6299120000002207 | ### Click to Pay Please refer to[ this chapter](/home/integration-guide/payment-methods/click-to-pay.md#testing) to test Click to Pay. ### Diners Club International & Discover Card It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: {% hint style="info" %} Discover is tested as Diners due to their similarities. {% endhint %} | Card Number | Test case | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9050003150000002 |

Frictionless Y. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true

| | 9050003250000001 |

LiabilityShift can't be granted due to technical reasons. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: N/A

| | 9050004950000002 |

Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true

| | 9050004250000009 |

Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false

| | 9050004350000008 |

Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case.
Liability shift: N/A, Authenticated: N/A

| | 9050004550000006 |

3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift. Card goes through a challenged flow beforehand.
Liability shift: false, Authenticated: false

| ### e-przelewy
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined Refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test e-przelewy. {% endhint %} ### eps {% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test eps. {% endhint %} ### Google Pay Simply activate Google Pay for your terminal on the test environment (see [Google Pay Activation](/home/integration-guide/payment-methods/google-pay.md#activation)). That will take care of everything necessary for the [Payment Page](/home/integration-guide/licences-and-interfaces/payment-page.md). Google Pay on the Payment Page also supports {% hint style="warning" %} Please only activate the **Google Pay Simulator** for testing. Activating standard Google Pay will lead to processing issues and thus does not work. {% endhint %} For the Server-to-Server method, you can use our [normal test cards](/home/integration-guide/testing-and-go-live.md#simulators-and-test-cards) in conjunction with our [Google Pay Token generator](https://test.saferpay.com/Simulators/GooglePay/PaymentTokenGenerator) in order to test Google Pay Server-To-Server using the normal test cases our cards offer you. The generated payment tokens just simply have to be submitted to Saferpay [as described above](#google-pay-server-to-server). ### Gutschein OeV | Card Number | Test case | | ----------------------------------- | ---------------- | | Success | 2207870000000011 | | Generic Decline | 2207870000000201 | | Card expired | 2207870000000235 | | Card unknown | 2207870000000243 | | Card locked | 2207870000000250 | | No funds | 2207870000000268 | | Card for simulating a failed refund | 2207870000002207 | ### iDEAL Saferpay does offer an extensive iDEAL simulator. All test cases are controlled through the simulator UI when opening up the payment page. {% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test iDEAL. {% endhint %} {% hint style="warning" %} The following cases must be simulated via amount and not the GUI. **Simply do a redirect without selecting a case on the GUI.** {% endhint %}
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
49600ttThe execution of the (unsuccessful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
### JCB It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: | Card Number | Test case | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9060003150000000 |

Frictionless Y. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true

| | 9060004950000000 |

Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true

| | 9060004250000007 |

Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false

| | 9060004350000006 |

Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case.
Liability shift: N/A, Authenticated: N/A

| | 9060002750000006 |

3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: false

| ### Klarna Payments Saferpay does offer an extensive Klarna Payments simulator and also the possibility to work on the Klarna Sandbox. All test cases are controlled through the UI; however, you must follow the rules under [Integration](/home/integration-guide/payment-methods/klarna-payments.md#integration), or Klarna won't be displayed. Please refer to the [Activation section](/home/integration-guide/payment-methods/klarna-payments.md#activation-on-the-test-environment) to see how to activate Klarna Payments on the test environment. ### Lunch-Check | Card Number | Test case | | ----------------------------------- | ---------------- | | Success | 6375940000000019 | | Generic Decline | 6375940000000209 | | Card expired | 6375940000000233 | | Card unknown | 6375940000000241 | | Card locked | 6375940000000258 | | No funds | 6375940000000266 | | Card for simulating a failed refund | 6375940000002205 | ### Maestro International It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: | Card Number | Test case | | ---------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9040003150000005 |

Frictionless Y. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true

| | 9040003550000001 |

LiabilityShift can't be granted due to technical reasons. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: N/A

| | 9040004950000005 |

Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true

| | 9040004250000002 |

Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false

| | 9040004350000001 |

Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case.
Liability shift: N/A, Authenticated: N/A

| | 9040004350000001 |

3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift. Card goes through a challenged flow beforehand.
Liability shift: false, Authenticated: false

| ### Mastercard It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards:
Card NumberTest case
Card NumberTest case
9030003150000007Frictionless Y. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true
5555555555554444Frictionless Y following real Mastercard card format. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true
9030003750000001LiabilityShift can't be granted due to technical reasons. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: N/A
9030004950000007Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true
9030004250000004Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false
9030004350000003Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case!
Liability shift: N/A, Authenticated: N/A
90300041500000053DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter, to stop authorizations without LiabilityShift. Card goes through a challenged flow beforehand.
Liability shift: false, Authenticated: false
9030403104000006Frictionless Y with DCC. This card additionally will perform DCC. Card currency is USD.
Liability shift: true, Authenticated: true
9030503104000003Frictionless Y with DCC. This card additionally will perform DCC. Card currency is JPY.
Liability shift: true, Authenticated: true
9030403153150009General Decline. This card fails the authorization and also the card check.
Liability shift: true, Authenticated: true
9030403153900007

Card for simulating response codes via the amount. The last two digits inside the amount are important. Down below you'll find some examples for return codes/amounts. The codes must be the last digits of the amount, e.g., 123nn.

Important note: These are the most common codes. However, some issuers may return codes not on this list.

00: See Frictionless Y

01: Successful Authorization and 3DS process. However LiabilityShift will be rejected during authorization.

62: Restricted card

51: Insufficient funds

43: Stolen card

34: Suspicion of manipulation

33: Card expired

30: Format error

14: Invalid card

12: Invalid transaction

09: Processing temporarily not possible

05: Authorization declined

04: Card invalid

03: Invalid merchant number

9030100000021017Card to simulate a partial approval.
9030103204160003Card to simulate a Soft Decline. This card will ALWAYS return a Soft Decline, even if SCA was performed.
9030100000001019For Issuer Installments: One fixed installment plan.
9030100000002017For Issuer Installments: Many fixed installment plans.
9030100000003015For Issuer Installments: Custom Plan.
### PayPal
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
### PostFinance Pay
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test PostFinance Pay. {% endhint %} | IBAN | Test-case | | --------------------- | ------------------- | | CH6309000000250097798 | **Instant Payouts** | When using Instant Payouts, one controls the outcome of a transaction via the amount. Any other amount will result in a success. | Amount | Test-case | | -------- | -------------------------- | | 11022000 | **Authorization declined** | ### Reka
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test Reka. {% endhint %} ### SEPA Direct Debit It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test IBANs: | IBAN | Test case | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | DE17970000011234567890 | **"Success IBAN"**. IBAN to simulate a successful transaction. | | DE52970000021234567890 |

IBAN to "simulate response codes".
IBAN for controlling authorisation codes via the amount.
210nn simulates a decline, where "nn" is the simulated decline code.
Requests with other amounts simulate positive responses.

| ### TWINT On the test environment, Saferpay offers a TWINT Simulator for the currency CHF only, since this Payment Method is only available for the Swiss market.\ The Simulator is controlled by submitting different amount values to simulate the following cases: {% hint style="warning" %} The "Abort" button does not work unless a decline amount is set. It would result in an abort, and then, after the 20 seconds (see below) have expired, the transaction is successful. All test cases are amount controlled. {% endhint %} {% hint style="info" %} Any other amount will cause a success after 20 seconds! {% endhint %}
AmountTest casePayment PageUser on File
AmountTest casePayment PageAuthorize Direct
40200ttThe execution of the (successful) authorization is delayed by tt seconds.✅❌
4120000Authorization declined✅✅
4220000Authorization expired✅❌
4320000Authorization cancelled✅❌
7120000Declined refund❌❌
### UnionPay Saferpay does offer an extensive UnionPay simulator. All test cases are controlled through the simulator UI when opening up the Payment Page. However, you need to use the following test card, in order to activate it: **9100104952000008.** ### Visa & V PAY It may be important to test certain flows and responses during integration. For that, Saferpay offers the following test cards: {% hint style="info" %} V PAY is tested and processed as Visa. {% endhint %} | Card Number | Test case | | ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 9010003150000001 |

Frictionless Y. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true

| | 4111111111111111 |

Frictionless Y following real VISA card format. Card simulates a fully successful Frictionless Flow.
Liability shift: YES, Authenticated: true

| | 9010003750000005 |

LiabilityShift can't be granted due to technical reasons. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift.
Liability shift: false, Authenticated: N/A

| | 9010004950000001 |

Challenged Y. This card simulates a successful challenged flow.
Liability shift: true, Authenticated: true

| | 9010004250000008 |

Challenged A. The authentication was not successful, but LiabilityShift is still granted.
Liability shift: true, Authenticated: false

| | 9010004350000007 |

Challenged N. The 3DS authentication failed. An authorization will not be attempted. The transaction fails in this case.
Liability shift: N/A, Authenticated: N/A

| | 9010004150000009 |

3DS Failure, authorization will be attempted. This card fails the 3DS authentication. Interesting for testing the Condition parameter to stop authorizations without LiabilityShift. Card goes through a challenged flow beforehand.
Liability shift: false, Authenticated: false

| | 9010403104000000 |

Frictionless Y with DCC. This card additionally will perform DCC. Card currency is USD.
Liability shift: true, Authenticated: true

| | 9010503104000007 |

Frictionless Y with DCC. This card additionally will perform DCC. Card currency is JPY.
Liability shift: true, Authenticated: true

| | 9010403153150003 |

General Decline. This card fails the card check.
Liability shift: true, Authenticated: true

| | 9010403153900001 |

Card for simulating response codes via the amount. The last two digits inside the amount are important. Down below you'll find some examples for return codes/amounts. The codes must be the last digits of the amount, e.g., 123nn.

Important note: These are the most common codes. However, some issuers may return codes not on this list.

00: See Frictionless Y

01: Successful Authorization and 3DS process. However LiabilityShift will be rejected during authorization.

62: Restricted card

51: Insufficient funds

43: Stolen card

34: Suspicion of manipulation

33: Card expired

30: Format error

14: Invalid card

12: Invalid transaction

09: Processing temporarily not possible

05: Authorization declined

04: Card invalid

03: Invalid merchant number

| | 9010100000020013 | Card to simulate a [partial approval](https://saferpay.github.io/sndbx/creditcards.html#cc-pappoval). | | 9010103204160007 | Card to simulate a [Soft Decline](https://saferpay.github.io/sndbx/psd2.html#psd2-decline). **This card will ALWAYS return a Soft Decline, even if SCA was performed.** | ### WeChat Pay On the test environment, Saferpay offers a WeChat Pay Simulator.\ The Simulator is controlled by submitting different amount values to simulate the following cases: {% hint style="warning" %} The "Abort" button does not work unless a decline amount is set. It would result in an abort, and then, after the 20 seconds (see below) have expired, the transaction is successful. All test cases are amount controlled. {% endhint %} {% hint style="info" %} Any other amount will cause a success after 20 seconds! {% endhint %}
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
### Wero
AmountTest case
AmountTest case
40200ttThe execution of the (successful) authorization is delayed by tt seconds.
4120000Authorization declined
4220000Authorization expired
4320000Authorization cancelled
7120000Declined refund
{% hint style="info" %} Please [contact the Integration Support](/home/integration-guide/support.md#integration-support) if you want to test Wero. {% 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://docs.saferpay.com/home/integration-guide/testing-and-go-live.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.