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:
Complete Integration Testing
Test your integration thoroughly using our sandbox environment and test cards.
Submit Certification Request
Email us with your integration details and test results for review.
Complete Verification Checklist
Review and confirm all integration requirements are properly implemented.
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:
- Email Subject:
Integration Sign-off - [Your Account Name]
- Test Results: Share all requested details from the Test the Integration section below
- Verification Confirmation: Complete the Verify the Integration checklist
- 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.
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:
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
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
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
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.
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
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 |
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
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 |
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
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 |
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
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 |
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
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 |
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 Services3- 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 parameterDetect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation requestSending 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 Services3- 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 parameterDetect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation requestSending 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 Services3- 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 parameterDetect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation requestSending 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 Services3- 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 parameterDetect the public IP address for the customer who's browsing your website/application and pass it to customer_ip parameter in the Payment Operation requestSending 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 Services3- 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 Services3- 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 request2- 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:
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)
Review Process
Our technical team will review your submission within and may request additional information or clarifications if needed.
Production Credentials
Upon successful certification, you'll receive:
- Production account credentials
- Live environment endpoints
- Production configuration guidelines
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