Certification
Certification steps, required test cases, and the evidence to submit before your integration goes live.
Before going live, complete certification so that the payment flows your integration supports can be reviewed. The test cases and submission steps are listed below.
Certification steps
Choose the applicable test cases
Identify which flows your integration supports:
- Card not present: online card collection, stored-card payments, and their follow-up operations.
- Card present: payments and tokenization on a physical terminal.
- Omni-channel: 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@doura.ca to confirm the applicable certification cases. See ACH bank transfers for supported operations.
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 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.
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. |
Submit the certification package
Share the applicable test results and integration evidence with support@doura.ca 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.
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 when retrieving a customer's stored methods.
For the relevant endpoints and operation rules, see Card not present, Tokenization, and Transaction types.
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 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 for how tokens work across channels.
Before switching to production
Verify webhook handling
Verify signatures and confirm that the endpoint saves and acknowledges events. See Webhooks.
Verify your redirect or callback handling
If you use the Hosted Payment Form, that includes verifying the redirect hash and validating postMessage origins.
For the Payment SDK, verify both onComplete and onError handling. onComplete can report a decline; see Callback payloads.
Validate wallet domains, if applicable
Complete the required domain validation for Apple Pay and Google Pay during certification. See Apple Pay and Google Pay.
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 and SDK configuration.
Related
- Test cards - approval, decline, and error scenarios
- Errors and rate limits - handling failed and uncertain requests
- Webhooks - verifying and processing transaction events