--- updatedAt: 2026-10-05T06:02:52.000Z agentTools: projectIndex: https://docs.tamara.co/llms.txt --- # Online Go-Live Testing Checklist For online website, mobile apps implementation, etc. # **Brand Guidelines** * ✅ Branding on merchants' interface should match: Tamara Branding Guidelines * ✅ **Tamara** logos should match: Tamara logo and brand assets * ✅ **Tamara** as a payment option, is shown with the right labels, wherever applicable * ✅ **Tamara's** icon is shown next to the options or wherever payment options are listed (footer, cart page, etc.) * ✅ Widgets on merchants' interface should match: Tamara Widget Guidelines * \[KSA 🇸🇦] Tamara Widget Implementation Guidelines * \[UAE 🇦🇪] Tamara Widget Implementation Guidelines * ✅ Widget behavior is correct on both desktop and mobile web * ✅ Widget behavior is correct on mobile apps (if applicable) # **Payment options** * ✅ Pre-check is implemented and **Tamara** is offered only to eligible customers; greyed-out for ineligible customers. * ✅ **Tamara** as a payment option, is shown within range based on the min/max configurations set for the merchant account # **Checkout** We now support **Auto-authorisation**! * ✅ Users can trigger checkout and complete it successfully * ✅ Checkout language (English/Arabic) matches the store interface * ✅ Checkout details match the order at the store * ✅ Order status matches the expected status on order completion * ✅ *\[If auto-authorise is not enabled]* If the order is not Authorised within 72 hours from when it is Approved, **Tamara** marks it as Expired. * ✅ If the checkout session is manually Cancelled by the customer, **Tamara** marks it as Expired immediately, instead of waiting for the default checkout session expiry time. * ✅ Order payload is passed correctly (order reference id, items' details, totals, consumer details, platform details, mobile/web details) * Is the merchant order\_reference\_id being reused in any case? If yes, please provide justification to avoid future order mapping or reconciliation issues. * ✅ If the integration manager has shared specific Risk Assessment parameters with the merchant, then need to ensure that they are being passed in order creation requests. * For critical lines of businesses, please ensure to review the documentation here: Specific details for risk assessment * ✅ Customer is re-directed correctly in all scenarios * ✅ Success * ✅ Cancelation * ✅ Failure * To test the Declined scenario, it can be done using: the Decline scenario provided here * ✅ Checkout is checked on both desktop and mobile web * ✅ Checkout is checked on mobile apps (if applicable) * ✅ ID verification flow should be working on all platforms, such as Web, Mobile Web, Mobile apps: * ✅ If KSA setup is enabled, need to ensure that Nafath ID verification flow is working fine. * (a)To test, please follow the instructions here: For 🇸🇦 KSA Nafath ID verification process * (b) If the integration is on WebView, please ensure the Nafath redirection is tested on production setup before going live. * ✅ If UAE setup is enabled, need to ensure that Uqudo ID verification flow is working fine. * To implement, please review the documentation here: UAE ID Verification # **Post-Order** * ✅ Communication with customer mentions **Tamara** as the payment method * ✅ Customers receive order updates on shipping (from the merchant, if **Tamara** capture notifications are off) # **Order Management** * ✅ *\[If auto-authorise is not enabled]* Order authorisation happens automatically after order approval without any issue * ✅ Order updates are triggered correctly from the dashboard or merchant OMS, if integrated, and reflect correctly at **Tamara** * ✅ Order status at merchant end and **Tamara** end are synced/matched * ✅ Check for order status - Pull Mechanism using Get order status API * ✅ Cancellation flow (a cancel API call is triggered to **Tamara** on cancelation happening from different initiation points) (not applicable if Auto-capture is enabled) * ✅ Full cancellation * ✅ Partial cancellation\* * ✅ Capture flow ( a capture API call is triggered to **Tamara** on shipping the order ) (applicable only if Auto-capture is not enabled) * ✅ Full capture * ✅ Partial capture\* (not applicable if Auto-capture is enabled) * ✅ Refunds flow (a refund API call is triggered to **Tamara** on refund happening from different initiation points) * ✅ Full refund * ✅ Partial refund\* * ✅ All **Tamara** orders refunds are handled over **Tamara** ONLY; refund to store wallet, etc., is NOT allowed. * ✅ Webhook(s) correctly configured \["Approved", "Authorised", "Captured", "Canceled", "Refunded", "Expired", "Declined" events.] # **Status Page** * ✅ Relevant merchant stakeholders should subscribe to statuspage.tamara.com to get notifications regarding any planned maintenance activities, system updates or incidents. # **Tamara SSL certificate** * ✅ ONLY for merchants using SSL certificate pinning to connect with **Tamara** system - a security measure that ensures connections are only made to trusted servers like **Tamara** - Integration Manager or Account Manager to provide the latest certificate, on requirement. # **Tamara IPs whitelisting** * ✅ ONLY for merchants needing to whitelist **Tamara** IPs to connect with **Tamara** system - Integration Manager or Account Manager to provide the latest list of IPs, on requirement. *\*To be covered if you support such cases in your store's flow*