Go-Live Checklist

Copy page

Copy page as Markdown for LLMs

Open in ChatGPT

Ask questions about this page

Open in Claude

Ask questions about this page

Ready to take your payment integration live? This comprehensive checklist ensures your integration meets all requirements for production deployment. Follow the step-by-step process to complete testing, verification, and certification for your Amazon Payment Services integration.

Getting Started

The go-live process follows these essential steps:

1

Complete Integration Testing

Test your integration thoroughly using our sandbox environment and test cards.

2

Submit Certification Request

Email us with your integration details and test results for review.

3

Complete Verification Checklist

Review and confirm all integration requirements are properly implemented.

4

Production Account Setup

Receive your production credentials and go live with real transactions.

Certification Request

To begin the certification process and create your production account, email us at integration-ps@amazon.com

Include the following information in your certification email:

1. Email Subject: Integration Sign-off - [Your Account Name]
2. Test Results: Share all requested details from the Test the Integration section below
3. Verification Confirmation: Complete the Verify the Integration checklist
4. Local Payment Methods: If using local payment options (MADA, STCPAY, etc.), ensure both generic and payment-specific requirements are covered

Test the Integration

Complete comprehensive testing of your integration using our sandbox environment. This section outlines all required test scenarios and documentation needed for certification.

General Testing

Core testing requirements including screenshots, test scenarios, and documentation for all integration types.

Apple Pay Testing

Specific testing requirements for Apple Pay integration including test cards and code snippets.

KNET Testing

Kuwait-specific testing requirements for KNET payment method integration.

NAPS Testing

Qatar-specific testing requirements for NAPS payment method in Arabic and English.

BENEFIT Testing

Bahrain-specific testing requirements for BENEFIT payment method integration.

OmanNet Testing

Oman-specific testing requirements for OmanNet payment method integration.

STCPAY Testing

Saudi Arabia-specific testing requirements for STCPAY wallet integration.

General Testing

Required Screenshots

Submit the following screenshots in a .zip or .pdf file (max 20MB). Ensure URLs are visible in all screenshots:

Screenshot	Purpose	Requirements
Pre-checkout page	Confirms MADA branding implementation	Required for MADA users
Checkout page	Validates payment form integration	Show payment options and form fields
3D Secure page	Ensures 3DS displays in main window	Must not open in popup/iframe
Success/failure pages	Verifies transaction outcome messaging	Include both success and failure scenarios
Tokenization code	Required for mobile Custom Merchant Page	Show code snippet implementation
Save card flow	Demonstrates saved card experience	Show checkbox and auto-filled fields
Delete saved card	Verifies card removal functionality	Show customer can delete saved cards
Recurring setup	Shows subscription consent flow	Include subscription button and plan details

Required Test Scenarios

Execute all test scenarios using our test card numbers:

1

Basic Payment Tests

Required Tests:

• ✅ Successful transaction (Non-3DS card)
• ✅ Successful transaction (3DS card)
• ✅ Declined transaction (declined card)

Documentation: Share merchant reference numbers for each test case

2

Enhanced Features

If Applicable:

• ✅ Installments success test
• ✅ MADA success test (for SAR currency)
• ✅ Save card request with CVV and token name
• ✅ Delete card with UPDATE_TOKEN request

Documentation: Include screenshots and merchant references

3

Recurring Payments

If Using Recurring:

• ✅ Initial recurring transaction setup
• ✅ Subsequent recurring payment
• ✅ Recurring payment modification/cancellation

Documentation: Provide agreement IDs and transaction references

Only use our official test card numbers for certification testing. Real card numbers will not work in the sandbox environment and may cause security issues.

Apple Pay Integration Testing

1

Transaction Testing

Simulate a successful Apple Pay transaction using Apple test cards and share the merchant references.

Use Apple's official test cards for Apple Pay testing. Ensure transactions are processed through the Apple Pay interface, not regular card entry.

2

Code Documentation

Provide the following code snippets:

• Supported payment networks (must include MADA and Amex)
• Merchant capability settings

Required Networks:

• ✅ MADA (for Saudi Arabia)
• ✅ American Express
• ✅ Visa
• ✅ Mastercard

KNET Integration Testing

Currency: KWD (Kuwaiti Dinar) | Country: Kuwait

1

Screenshot Requirements

Submit screenshots for both success and declined transactions:

Screenshot	Description
Pre-checkout page	Product/buy page showing KNET option
Checkout page	Payment selection with KNET highlighted
KNET payment page	Official KNET payment interface
KNET confirmation	KNET transaction confirmation screen
Receipt page	Post-checkout return with transaction details

2

Documentation Requirements

• Include two separate .zip files (success & declined scenarios)
• Share merchant references for both test cases
• Ensure all screenshots show visible URLs in browser address bar

As a mandatory KNET requirement, you must display KNET-specific transaction IDs (knet_ref_number, third_party_transaction_number), payment amount, and transaction date on the receipt page.

NAPS Integration Testing

Currency: QAR (Qatari Riyal) | Country: Qatar

1

Multi-Language Testing

Submit screenshots of the complete payment flow in both Arabic and English:

Screenshot	Arabic	English
Pre-checkout page	✅ Required	✅ Required
Checkout page	✅ Required	✅ Required
NAPS payment page	✅ Required	✅ Required
NAPS confirmation	✅ Required	✅ Required
Receipt page	✅ Required	✅ Required

2

Transaction Scenarios

• Success transaction screenshots in separate .zip file
• Declined transaction screenshots in separate .zip file
• Share merchant references for both scenarios

Follow QPAY PG certification guidelines and UI best practices for successful NAPS integration certification.

BENEFIT Integration Testing

Currency: BHD (Bahraini Dinar) | Country: Bahrain

1

Screenshot Requirements

Submit comprehensive screenshots covering:

Screenshot	Purpose
Pre-checkout page	Shows product/service selection
Checkout page	BENEFIT option clearly visible
BENEFIT payment page	Official BENEFIT payment interface
Order confirmation	Transaction confirmation screen
Post-checkout return	Final receipt/confirmation page

2

Test Scenarios

• Success transaction - Complete payment flow
• Declined transaction - Failed payment handling
• Organize screenshots in separate .zip files by scenario
• Provide merchant references for validation

Ensure BENEFIT branding guidelines are followed when displaying the BENEFIT payment option on your checkout page.

OmanNet Integration Testing

Currency: OMR (Omani Rial) | Country: Oman

1

Complete Flow Documentation

Submit screenshots covering the entire payment journey:

Screenshot	Description
Pre-checkout page	Product selection page
Checkout page	OmanNet option selection
OmanNet payment page	Official OmanNet interface
OmanNet OTP page	One-time password verification
Order confirmation	Transaction success confirmation
Post-checkout return	Final receipt page

2

Submission Requirements

• Compile all screenshots in single .zip file
• Include both success and declined test scenarios
• Share merchant references for transaction validation

STCPAY Integration Testing

Currency: SAR (Saudi Riyal) | Country: Saudi Arabia

1

Payment Flow Screenshots

Document the complete STCPAY payment experience:

Screenshot	Description
Pre-checkout page	Product/service selection
Checkout page	STCPAY option clearly displayed
STCPAY payment flow	Phone number input and OTP verification
Post-checkout return	Transaction completion page

2

Test Documentation

• Success scenario - Complete .zip file with successful payment flow
• Declined scenario - Separate .zip file showing payment failure handling
• Merchant references - Share transaction IDs for both test cases

Ensure you detect and pass the actual customer phone_number and OTP values dynamically. Static values in API requests will cause integration failures.

Verify the Integration

Go through the below verification criteria and make sure you have implemented them. We will send to you the below points as checklist form you need to submit, to confirm your sign-off.

Hosted Checkout

Verification checklist for Hosted Checkout integration including security, validation, and branding requirements.

Custom Integration - Non-PCI

Verification requirements for Custom Integration without PCI certification including tokenization and 3DS handling.

Custom Integration - PCI Certified

Verification checklist for PCI-certified merchants using Custom Integration with enhanced security requirements.

Mobile Integration

Mobile SDK integration verification including token generation, SDK versions, and security requirements.

Apple Pay Integration

Apple Pay specific verification requirements for both merchant page and mobile SDK implementations.

Recurring Payments

Recurring payment integration verification including agreement handling and token management.

Hosted Checkout Verification

Check Point	Integration and Definition
Detect Customer Email Address	Detect the customer Actual email address and pass it to customer_email parameter. Sending static value to customer_email parameter will cause the transaction to be blocked by our fraud detection tool in production environment
Accept responses returned as POST FORMs	The return_url submitted in the API Request accepts the response returned as POST FORM since in the production environment you will have only POST Method option to receive the responses. In addition, the value passed to return_url parameter in the API Request should be https
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs. - Kindly avoid configuring any invalid URLs such as (apple.com, google.com, example.com …etc) in your accounts (test/production).If you are planning to use our accounts only for Invoicing/Subscription/E-terminal solutions, and you don't have any active connection and integration between your website and Amazon Payment Services account, please use your domain URL / Terms & conditions URL for all the fields listed in your technical settings tab.)
Amount Validation	Remember to validate the actual amount deducted from the customer, as it should matches the same amount you submit in the API requests to Amazon Payment services. This is required to protect your website from any fraud
The command parameter value PURCHASE or AUTHORIZATION	PURCHASE command means that the amount will be fully deducted from the customer's card to your bank account (The amount is Automatically captured) AUTHORIZATION command means that the amount will be held from the customer's card without capturing , the capture for the authorized amount should be done from your side manually through the back-office under Order Transaction Management tab or automatically through our APIs. You can find more details in the API documentation section Payment maintenance operations
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
MADA	You need to follow MADA Branding Document to add MADA branding in the checkout page
NAPS	This document covers the guidelines that you need to follow to conclude the certification successfully with QPAY PG QPAY Certification Guidelines and UI Best Practices
BENEFIT	You need to follow BENEFIT Branding Document to add BENEFIT payment button
Knet	As a mandatory Knet requirement, you must display two Knet related ID's (knet_ref_number ,third_party_transaction_number) , payment amount and transaction date in the receipt page which is the page that the customer will be redirected to it after processing the payment
Amex	You need to follow AMEX branding guidelines to add amex branding

Your website was tested on Google Chrome web browser. We encourage you to test it on other browsers and from different Operating systems and confirm normal operations.

Custom Integration - Non-PCI Certified Merchant Verification

Check Point	Integration and Definition
Detect Customer Email Address and IP	Detect the customer Actual email address and pass it to customer_email parameter Detect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation request Sending static value to customer_email or customer ip parameter will cause the transaction to be blocked by our fraud detection tool in production environment
Accept responses returned as POST FORMs	The return_url submitted in the API Request accepts the response returned as POST FORM since in the production environment you will have only POST Method option to receive the responses. In addition, the value passed to return_url parameter in the API Request should be https
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs. - Kindly avoid configuring any invalid URLs such as (apple.com, google.com, example.com …etc) in your accounts (test/production).If you are planning to use our accounts only for Invoicing/Subscription/E-terminal solutions, and you don't have any active connection and integration between your website and Amazon Payment Services account, please use your domain URL / Terms & conditions URL for all the fields listed in your technical settings tab.)
Tokenization Service command	Submit Tokenization service_command as POST FORM, from client side (browser/mobile app) only. It is a PCI mandate to submit this request from client side & you should not process/store/handle/log/save clear card details
Dynamic Controller for 3DS	Remember to implement a dynamic controller from your end to handle the 3DS service , if you receive the 3ds_url you can redirect the customers to it , otherwise "if it's "NULL" you need to consider the final response returned to you in JSON body and update the customer in his checkout page about the final payment status.
Amount Validation	Remember to validate the actual amount deducted from the customer, as it should matches the same amount you submit in the API requests to Amazon Payment services. This is required to protect your website from any fraud
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
Advanced Fraud Tool( ReD )	If you agreed with your account manager to have our Advanced Fraud Tool ( ReD ) active in your production account To protect your transactions you need to add the device_fingerprint parameter in the purchase/authorization request using our script to generate the value, check our device fingerprint script
MADA	You need to follow MADA Branding Document to add MADA branding in the checkout page
Amex	You need to follow AMEX branding guidelines to add amex branding
STCPAY	Detect the actual phone_number and OTP filled by the customer in your checkout page without having them static in the API Requests

Your website was tested on Google Chrome web browser. We encourage you to test it on other browsers and from different Operating systems and confirm normal operations.

Custom Integration - PCI Certified Merchant Verification

Check Point	Integration and Definition
Detect Customer Email Address and IP	Detect the customer Actual email address and pass it to customer_email parameter Detect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation request Sending static value to customer_email or customer ip parameter will cause the transaction to be blocked by our fraud detection tool in production environment
Accept responses returned as POST FORMs	The return_url submitted in the API Request accepts the response returned as POST FORM since in the production environment you will have only POST Method option to receive the responses. In addition, the value passed to return_url parameter in the API Request should be https
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs. - Kindly avoid configuring any invalid URLs such as (apple.com, google.com, example.com …etc) in your accounts (test/production).If you are planning to use our accounts only for Invoicing/Subscription/E-terminal solutions, and you don't have any active connection and integration between your website and Amazon Payment Services account, please use your domain URL / Terms & conditions URL for all the fields listed in your technical settings tab.)
Dynamic Controller for 3DS	Remember to implement a dynamic controller from your end to handle the 3DS service , if you receive the 3ds_url you can redirect the customers to it , otherwise "if it's "NULL" you need to consider the final response returned to you in JSON body and update the customer in his checkout page about the final payment status.
Amount Validation	Remember to validate the actual amount deducted from the customer, as it should matches the same amount you submit in the API requests to Amazon Payment services. This is required to protect your website from any fraud
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
Advanced Fraud Tool( ReD )	If you agreed with your account manager to have our Advanced Fraud Tool ( ReD ) active in your production account To protect your transactions you need to add the device_fingerprint parameter in the purchase/authorization request using our script to generate the value, check our device fingerprint script
MADA	You need to follow MADA Branding Document to add MADA branding in the checkout page
Amex	You need to follow AMEX branding guidelines to add amex branding

Your website was tested on Google Chrome web browser. We encourage you to test it on other browsers and from different Operating systems and confirm normal operations.

Mobile Integration Verification

Check Point	Integration and Definition
Detect Customer Email Address and IP	Detect the customer Actual email address and pass it to customer_email parameter Detect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation request Sending static value to customer_email or customer ip parameter will cause the transaction to be blocked by our fraud detection tool in production environment
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs. - Kindly avoid configuring any invalid URLs such as (apple.com, google.com, example.com …etc) in your accounts (test/production).If you are planning to use our accounts only for Invoicing/Subscription/E-terminal solutions, and you don't have any active connection and integration between your website and Amazon Payment Services account, please use your domain URL / Terms & conditions URL for all the fields listed in your technical settings tab.)
Amount Validation	Remember to validate the actual amount deducted from the customer, as it should matches the same amount you submit in the API requests to Amazon Payment services. This is required to protect your website from any fraud
The SDK_TOKEN generation	You need to handle the SDK_TOKEN generation from your server side not from the application, since this API request contains your security settings values which shouldn't pass your application, that's why we shift the signature calculations to the back-end not to be in the mobile application for any reverse engineering may occur
You are using the latest SDK version	Check Amazon Payment Services repositories on github to get the latest Mobile SDK version Amazon Payment Services
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
MADA	You need to follow MADA Branding Document to add MADA branding in the checkout page
Amex	You need to follow AMEX branding guidelines to add amex branding

Apple Pay Integration Verification

Merchant Page Implementation:

Check Point	Integration and Definition
Detect Customer Email Address and IP	Detect the customer Actual email address and pass it to customer_email parameter Detect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation request Sending static value to customer_email or customer ip parameter will cause the transaction to be blocked by our fraud detection tool in production environment
Accept responses returned as POST FORMs	The return_url submitted in the API Request accepts the response returned as POST FORM since in the production environment you will have only POST Method option to receive the responses. In addition, the value passed to return_url parameter in the API Request should be https
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs
Amount Validation	Remember to validate the actual amount deducted from the customer, as it should matches the same amount you submit in the API requests to Amazon Payment services. This is required to protect your website from any fraud
Supported Payment methods	Make sure that you have chosen mada and Amex as one of the supported payment network in your Apple Pay integration. For more details about the supported Payment Networks you can add in your current Integration, please refer to the reference from Apple Supported Networks
MADA considerations	Set country code as SA for mada payments on Apple pay, here is the URL for your reference: Country Codes
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
Applepay capability	Set the merchant capability in your apple pay website integration as: supports3DS. For more details about merchant capability, please refer to this reference from Apple merchantCapabilities

Mobile SDK Implementation:

Check Point	Integration and Definition
The SDK_TOKEN generation	You need to handle the SDK_TOKEN generation from your server side not from the application, since this API request contains your security settings values which shouldn't pass your application, that's why we shift the signature calculations to the back-end not to be in the mobile application for any reverse engineering may occur.
You are using the latest SDK version	Check Amazon Payment Services repositories on github to get the latest Mobile SDK version Amazon Payment Services
Applepay capability	Set the merchant capability in your apple pay SDK integration as: capability3DS. For more details about merchant capability, please refer to this reference from Apple merchantCapabilities

Recurring Payments Verification

Check Point	Integration and Definition
Request and Response Signature Calculations and validations	1- While calculating the request signature, make sure to exclude the empty parameters (without values) from the signature calculations to avoid mismatch, this is applicable for all API requests submitted to APS 2-For the response signature, You need to validate the signature you receive from Amazon Payment Services by calculating the signature for the response parameters you receive on the return_url once the transaction is processed using the SHA response phrase listed in your test account under: Integration settings >> Security settings, the value of the calculated signature should match the value of the signature returned from Amazon Payment Services 3- Please make sure that you are handling the response as it is returned from APS without trimming any trailing spaces so you can be able to validate response signature correctly 4- Identify your request and response SHA phrases and make sure to do the signature calculations from your back-end only
Transaction Feedback Implementation	Your code handles the response parameters received on Check Status API or Direct Transaction Feedback for payment instant responses and Notification Feedback URL for the recovery responses under Technical Settings, In this step, you need to create an endpoint to receive response parameters as a POST Method. To configure these URLs, please go to your Technical Settings Tab in your Amazon Payment services account and click on the activated channel you have, then configure the URL under Direct Feedback and Notification Feedback URLs. - Kindly avoid configuring any invalid URLs such as (apple.com, google.com, example.com …etc) in your accounts (test/production).If you are planning to use our accounts only for Invoicing/Subscription/E-terminal solutions, and you don't have any active connection and integration between your website and Amazon Payment Services account, please use your domain URL / Terms & conditions URL for all the fields listed in your technical settings tab.)
Different Inbound Server IP in Sandbox and Production	Remember to not use the same Inbound server IP you are currently using in Sandbox environment to submit the API Requests in the Production environment while submitting API requests for real payments to avoid impacting both environments
Recurring Validation	1- You should send the parameter recurring_mode in the initial e-commerce/CIT request 2- Incase you are using Fixed/Variable recurring_mode, you should be sending the recurring_transactions_count, recurring_expiry_date, recurring_days_between_payments parameters in the initial e-commerce/CIT request. 3- In the e-commerce/CIT request you should send a unique value for the parameter agreement_id "without any special characters and limited to a maximum length of 15 characters" 4- You should handle the value of agreement_id from the Ecommerce/CIT response, as it may differ from the one you originally submitted in the request. This difference is based on transaction processing, and the value should be used in subsequent recurring/MIT requests. 5- The same value for the token_name is used for both e-commerce/CIT requests and in subsequent recurring/MIT requests.

Next Steps

After completing your testing and verification, follow these final steps to go live:

1

Submit Certification Package

Email your complete certification package to integration-ps@amazon.com including:

• All required screenshots organized by integration type
• Test transaction merchant references
• Completed verification checklist confirmation
• Code snippets (if applicable)

2

Review Process

Our technical team will review your submission within and may request additional information or clarifications if needed.

3

Production Credentials

Upon successful certification, you'll receive:

• Production account credentials
• Live environment endpoints
• Production configuration guidelines

4

Go Live

Switch to production environment and start processing real transactions with confidence.

Support & Resources

Need help during the go-live process? Here are your support options:

• Technical Support: integration-ps@amazon.com
• Test Cards: Test Card Numbers
• Error Codes: Error Code Reference
• API Reference: Integration Guides
• SDKs: Software Development Kits