> For the complete documentation index, see [llms.txt](https://docs.omni.integratedcommerce.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.omni.integratedcommerce.io/going-live/go-live.md).

# Certification

Certification steps, required test cases, and the evidence to submit before your integration goes live.

Before going live, complete certification so Fiska can review the payment flows your integration supports. The test cases and submission steps are listed below.

## Certification steps

{% stepper %}
{% step %}

## Choose the applicable test cases

Identify which flows your integration supports:

* [Card not present](#card-not-present-test-cases): online card collection, stored-card payments, and their follow-up operations.
* [Card present](#card-present-test-cases): payments and tokenization on a physical terminal.
* [Omni-channel](#omni-channel-test-cases): using a token created on a physical terminal for an online payment.

Complete only the cases for operations your integration supports. Sale cases apply to sale flows; authorization and capture cases apply to integrations that use those separate operations. Include the corresponding decline cases.

For ACH bank-transfer scenarios, contact <support@integratedcommerce.io> to confirm the applicable certification cases. See [ACH bank transfers](/payments/ach.md) for supported operations.
{% endstep %}

{% step %}

## Run two examples of each applicable case

Use your sandbox API key and sandbox payment methods. Complete and retain **two examples for each applicable row** in the test tables below. For token removal and list operations, retain the operation results as the examples.

Use the [test cards](/going-live/test-cards.md) to produce approvals, declines, and processing errors. Card-present testing requires physical test cards suitable for the terminal.

Record the case name, the transaction ID or reference when applicable, and the result so the reviewer can locate each example. Check `resultCode` and `transactionResponses[].responseCode`: `status: Completed` can describe an approval or a decline. See [Retrieving transactions](/payments/transaction-retrieval.md).
{% endstep %}

{% step %}

## Collect the integration evidence

Include the following with your test results:

| Evidence                                 | What to show                                                                                                |
| ---------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| API key and payment method configuration | Screenshots or wireframes showing how the integration configures these values. Mask keys and other secrets. |
| Success and decline messaging            | The messages the customer sees for an approved payment and a declined payment.                              |
| Customer-facing errors                   | The messages shown when the checkout encounters an error.                                                   |
| Webhook receipt, when applicable         | Evidence that the integration successfully received the configured webhook events.                          |
| {% endstep %}                            |                                                                                                             |

{% step %}

## Submit the certification package

Share the applicable test results and integration evidence with <support@integratedcommerce.io> for review. Identify which channels and operations your integration supports. If you are unsure whether a case applies, confirm it with support before submitting the package.

Complete certification before switching the integration to production.
{% endstep %}
{% endstepper %}

## Card not present test cases

These cases cover online card flows through the Hosted Payment Form or Payment SDK and payments using stored card tokens. Run each supported row twice.

| Test case                           | Steps and result to demonstrate                                                                                                       |
| ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Hosted form: create token           | Open a tokenization session, enter a card, and obtain the stored payment method for a later payment.                                  |
| Hosted form: sale                   | Enter a card that is not already stored and complete an approved sale.                                                                |
| Hosted form: declined sale          | Use a declining test card in a sale session and show the declined result and customer message.                                        |
| Hosted form: authorization          | Enter a card that is not already stored and obtain an approved authorization for later capture.                                       |
| Hosted form: declined authorization | Use a declining test card in an authorization session and show the declined result and customer message.                              |
| Capture a hosted-form authorization | Capture an approved authorization created through the hosted form.                                                                    |
| Token sale                          | Complete an approved sale using a previously stored card token.                                                                       |
| Declined token sale                 | Attempt a sale with a stored test-card token that produces a decline and show the result.                                             |
| Token authorization                 | Obtain an approved authorization using a previously stored card token.                                                                |
| Declined token authorization        | Attempt an authorization with a stored test-card token that produces a decline and show the result.                                   |
| Capture a token authorization       | Capture an approved authorization created using a stored card token.                                                                  |
| Refund                              | Submit a referenced refund against an eligible completed sale or capture and show the result.                                         |
| Void an authorization               | Void an approved authorization while it is still eligible for cancellation.                                                           |
| Void a sale                         | Void an approved sale while it is still in the current batch.                                                                         |
| Void a capture                      | Void a completed capture while it is still in the current batch.                                                                      |
| Remove token after a sale           | Complete a sale, then remove the stored card token associated with it.                                                                |
| Remove token after an authorization | Complete an authorization, then remove the stored card token associated with it.                                                      |
| Remove token after a capture        | Complete a capture, then remove the stored card token associated with the original payment.                                           |
| Remove token after a refund         | Complete a refund, then remove the stored card token associated with the original payment.                                            |
| List transactions                   | Retrieve transaction records through `GET /transactions` and show the returned results.                                               |
| List payment methods                | Retrieve the merchant's available terminals and virtual payment methods through `GET /payment-methods` and show the returned results. |

Use separate active tokens for the token-removal examples. Remove them through `DELETE /payment-methods/token/{id}`. `GET /payment-methods` does not list tokens; use the [account holder's payment methods](/payments/account-holders.md#retrieving-an-account-holders-payment-methods) when retrieving a customer's stored methods.

For the relevant endpoints and operation rules, see [Card not present](/payments/card-not-present.md), [Tokenization](/payments/tokenization.md), and [Transaction types](/payments/payments.md#what-the-transaction-types-mean).

## Card present test cases

These cases use a physical payment terminal. Run each supported row twice.

| Test case              | Steps and result to demonstrate                                                                            |
| ---------------------- | ---------------------------------------------------------------------------------------------------------- |
| Create token           | Present a card on the terminal and obtain a stored payment method for later use.                           |
| Sale                   | Present a card on the terminal and complete an approved sale.                                              |
| Declined sale          | Run a terminal sale with a declining test card and show the declined result and customer message.          |
| Authorization          | Present a card on the terminal and obtain an approved authorization for later capture.                     |
| Declined authorization | Run a terminal authorization with a declining test card and show the declined result and customer message. |
| Capture                | Capture an approved authorization created on the terminal.                                                 |
| Refund                 | Submit a referenced refund against an eligible completed terminal sale or capture and show the result.     |
| Void an authorization  | Void an approved terminal authorization while it is still eligible for cancellation.                       |
| Void a sale            | Void an approved terminal sale while it is still in the current batch.                                     |
| Void a capture         | Void a completed capture from a terminal authorization while it is still in the current batch.             |

See [Card present](/payments/card-present.md) for the endpoints and terminal-specific results.

## Omni-channel test cases

If your integration reuses cards collected in person for online payments, provide two examples of each supported case below.

| Test case                                            | Steps and result to demonstrate                                                                                                        |
| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
| Card-present token to card-not-present sale          | Create a card token on a physical terminal, then use that token for an approved sale through `POST /transactions/token-sale`.          |
| Card-present token to card-not-present authorization | Create a card token on a physical terminal, then use that token for an approved authorization through `POST /transactions/token-auth`. |

See [Tokenization](/payments/tokenization.md) for how tokens work across channels.

## Before switching to production

{% stepper %}
{% step %}

## Verify webhook handling

Verify signatures and confirm that the endpoint saves and acknowledges events. See [Webhooks](/webhooks/webhooks.md).
{% endstep %}

{% step %}

## Verify your redirect or callback handling

If you use the Hosted Payment Form, that includes [verifying the redirect hash](/hosted-payment-form/redirect-verification.md) and [validating postMessage origins](/hosted-payment-form/best-practices.md#implement-proper-origin-validation).

For the Payment SDK, verify both `onComplete` and `onError` handling. `onComplete` can report a decline; see [Callback payloads](/payment-sdk/responses.md).
{% endstep %}

{% step %}

## Validate wallet domains, if applicable

Complete the required domain validation for Apple Pay and Google Pay during certification. See [Apple Pay and Google Pay](/going-live/wallets.md).
{% endstep %}

{% step %}

## Switch keys

After certification, replace the sandbox API key with the merchant's production key. Sandbox and production share a base URL, so the key selects the environment. If you use the Payment SDK, also set its `environment` to `prod`. See [Authentication](/get-started/authentication.md#environments) and [SDK configuration](/payment-sdk/configuration.md).
{% endstep %}
{% endstepper %}

## Related

* [Test cards](/going-live/test-cards.md) - approval, decline, and error scenarios
* [Errors and rate limits](/get-started/errors-and-rate-limits.md) - handling failed and uncertain requests
* [Webhooks](/webhooks/webhooks.md) - verifying and processing transaction events