Running a WooCommerce Store in Egypt and Saudi Arabia: VAT, ZATCA, Fawry, and RTL
Running a WooCommerce store in Egypt or Saudi Arabia requires more than translating checkout and installing a payment plugin. You need tax rules that match your business, an invoicing workflow that meets the relevant authority’s requirements, local payment methods, and Arabic layouts that work from product discovery through delivery.
WooCommerce provides the catalogue, cart, orders, and integration framework. The regional work happens around that core: Egypt’s standard 14% VAT rate, Saudi Arabia’s standard 15% rate, ZATCA and Egyptian Tax Authority systems, Fawry reference payments, Mada acceptance, and right-to-left presentation.
This guide follows the order in which those decisions should be made. Tax treatment and e-invoicing obligations depend on your registration, supplies, and applicable implementation phase; confirm them with your tax advisor and the relevant authority before launch.
What does WooCommerce need in Egypt and Saudi Arabia?
WooCommerce is an open-source ecommerce platform for WordPress. Its core software supports products, variations, stock, checkout, orders, coupons, tax tables, and basic shipping methods. Hosting, local payment acceptance, government e-invoicing integrations, and ongoing maintenance require separate decisions.
| Requirement | Egypt | Saudi Arabia |
|---|---|---|
| Standard VAT rate | 14%, where applicable | 15%, where applicable |
| E-invoicing authority | Egyptian Tax Authority: e-invoice and e-receipt systems | ZATCA: Fatoora e-invoicing |
| Payment priorities | Cards, Fawry, mobile wallets, and COD according to customer demand | Mada, cards, Apple Pay, and other methods supported by your acquiring agreement |
| Checkout localisation | Arabic, local phone formats, governorate and delivery-area fields | Arabic, local phone formats, and courier-compatible National Address fields |
| Operational dependencies | Payment callbacks, receipt or invoice submission, courier and COD reconciliation | Payment callbacks, invoice clearance or reporting, courier reconciliation |
Self-hosting gives you control over your database and application code. It also makes backups, updates, access controls, and recovery your responsibility. Third-party plugins, gateways, and hosting providers still introduce dependencies: owning the store does not remove the need to manage its suppliers.
When is WooCommerce the right platform?
WooCommerce is a strong candidate when you need custom B2B pricing, unusual checkout fields, ERP integration, complex product configuration, or a content-led storefront. Its flexibility is useful only if someone owns maintenance.
Compare Shopify, Salla, and Zid when a managed platform can meet your requirements with less operational work. Salla and Zid are particularly relevant to a Saudi-focused shortlist, but payment methods, e-invoicing capabilities, exports, and integrations must be checked against the specific plan and merchant account. Do not assume that any platform includes every Egyptian and Saudi requirement by default.
How to configure WooCommerce VAT for Egypt and Saudi Arabia
Start with your VAT obligations, not the tax settings screen. The standard rates are 14% in Egypt and 15% in Saudi Arabia, but not every product, transaction, or seller is treated identically. Registration status, exemptions, zero-rating, exports, and cross-border arrangements can change the result.
Once your advisor has confirmed the rules, enable taxes under WooCommerce settings and configure the Tax tab. The WooCommerce tax documentation explains the underlying settings; it does not determine your legal tax obligations.
Tax-inclusive display is different from tax-inclusive data entry
WooCommerce separates how you enter catalogue prices from how customers see them. You can enter prices excluding tax and still display consumer prices including tax. Choose the entry method that matches your accounting and product-import workflow, then configure shop, cart, and checkout displays to meet local consumer-pricing requirements.
Changing the entry method later without converting stored prices changes how WooCommerce interprets those amounts. For example, a stored price of SAR 115 represents SAR 100 plus SAR 15 VAT when entered inclusive of 15% VAT. The same stored amount entered exclusive of VAT produces a total of SAR 132.25.
| Setting | Implementation decision |
|---|---|
| Prices entered with tax | Choose inclusive or exclusive to match your catalogue data; document the choice before importing products. |
| Display prices in shop, cart, and checkout | Use the appropriate tax-inclusive consumer display and make the tax treatment clear. |
| Calculate tax based on | Select shipping, billing, or shop address according to the approved tax model. |
| Standard rate rows | Use country codes EG and SA where those rates apply; inspect wildcard rows for unintended matches. |
| Shipping tax class | Configure according to the tax treatment of delivery and the underlying supply. |
| Rounding | Align WooCommerce with the invoicing system and test both line-level and document-level totals. |
| Additional tax classes | Separate zero-rated and exempt treatment where required; they are not interchangeable accounting categories. |
Check the VAT calculation with real baskets
For a standard-rated tax-inclusive amount, VAT equals the gross amount multiplied by the rate divided by one plus the rate. An EGP 114 item at 14% contains EGP 14 VAT; a SAR 115 item at 15% contains SAR 15 VAT.
Test discounts, delivery charges, mixed tax classes, multiple quantities, and partial refunds. A simple one-item order can reconcile correctly while a discounted multi-line invoice fails validation. Do not assume that subtotal rounding universally fixes those differences.
Should you use one store or two?
One store can serve both markets, but two country tax rows and a currency switcher do not resolve cross-border compliance. Establish which legal entity sells each order, which registration applies, where stock ships from, and which entity issues the invoice.
Separate storefronts may simplify operations when the countries have different sellers, catalogues, warehouses, or payment contracts. A shared storefront can also work if its backend reliably routes orders to the correct seller and invoicing system. Decide this before generating live documents.
For B2B sales, collect the buyer’s required legal name, address, and tax identifiers in structured checkout fields. Store them with the order and expose them to the invoicing integration rather than relying on customer notes.
How WooCommerce connects to Saudi ZATCA e-invoicing
WooCommerce core does not provide ZATCA compliance. A suitable extension, middleware service, ERP, or custom integration must generate and manage compliant documents. A PDF with a VAT number and QR code is not, by itself, proof of compliance.
ZATCA’s generation phase and integration phase have different requirements. For taxpayers subject to Phase 2, standard tax invoices generally require clearance before being shared with the buyer, while simplified tax invoices must be reported within 24 hours of generation. Document type matters; do not treat every order as the same submission flow.
Confirm your applicable wave, onboarding steps, document requirements, and deadlines with ZATCA. A vendor’s listing or marketing claim is not a substitute for validating your implementation against the authority’s requirements.
Choose an invoicing system of record
- Middleware: a service receives WooCommerce data, generates the required documents, handles submission, and returns identifiers and status.
- ERP: WooCommerce sends orders to the accounting system, which owns invoice issuance and reconciliation.
- Direct integration: a custom application implements the applicable specifications, onboarding, signing, storage, and API workflows.
The right choice depends on your existing accounting setup and technical capacity. Check the actual connector and deployment rather than assuming an ERP brand or plugin name guarantees compliance.
Map invoice data before connecting the API
| Data | Source or owner |
|---|---|
| Seller identity and VAT registration | Verified legal-entity configuration |
| Buyer details and required identifiers | Validated checkout or business-account fields |
| Descriptions, quantities, discounts, and tax categories | Saved order line items |
| Invoice identifiers and sequence controls | Invoicing system, separate from the WooCommerce order number |
| Required hashes, stamps, and QR content | Compliant invoicing solution, according to document type and phase |
| Clearance or reporting outcome | Authority response stored against the invoice and linked order |
Agree the legal invoice trigger with finance. Waiting until an order reaches WooCommerce’s “Completed” status may be too late for your transaction model. Keep payment, fulfilment, invoice generation, and submission statuses separate.
Build durable queues, retry rules, duplicate prevention, and alerts for rejected submissions. A timeout should trigger a status check or safe retry, not a second invoice. Include credit and debit note handling where applicable, and preserve original issued documents rather than editing them after a refund.
Egyptian ETA e-invoices and e-receipts
Egypt operates separate e-invoice and e-receipt systems. The e-invoice system covers relevant business transactions, while e-receipts address consumer transactions under the applicable rollout. Your taxpayer status, transaction type, and implementation obligations determine the workflow.
Do not assume the two systems use identical signing, device-registration, or submission procedures. Confirm the applicable requirements with the Egyptian Tax Authority and its technical documentation.
Prepare the catalogue for structured submissions
- Item coding: map products to the applicable supported coding system, such as GS1 or EGS, and complete any required approval process.
- Units: map selling units to the authority’s accepted codes rather than sending unrestricted text.
- Tax categories: store the classifications required for your products and charges.
- Buyer and seller data: collect the identifiers required for the document type.
- Authentication and signing: implement the credentials, certificates, or device setup required by the relevant system.
Validate these fields during product imports. Missing codes are easier to fix before a catalogue goes live than after orders start generating rejected documents.
Your integration should retain submission identifiers, responses, and document status, with a reconciliation view for finance. The WooCommerce development services overview provides further context for planning the integration work.
Local WooCommerce payments: Fawry, Paymob, Mada, and COD
Choose your payment provider before finalising checkout. In Egypt, options to investigate include Fawry, Paymob, and Kashier. In Saudi Arabia, options include Moyasar, Tap, PayTabs, HyperPay, and Amazon Payment Services. Availability depends on the merchant’s entity, underwriting, contract, currency, and integration.
Confirm that the specific WooCommerce plugin supports your chosen payment methods, refunds, checkout implementation, and High-Performance Order Storage. A provider may offer a method through its API without supporting it in every plugin.
How Fawry reference payments should work
With a supported reference-payment flow, the customer places an unpaid order and receives a reference and payment deadline. Payment is confirmed later. That delay must be reflected in inventory, messaging, and fulfilment.
- Create the unpaid order: use the status defined by the integration and distinguish it from confirmed payment.
- Deliver the reference: show it and its expiry on the confirmation page and in readable Arabic and English notifications.
- Define stock policy: decide whether inventory stays reserved until expiry and what happens if payment arrives after stock is released.
- Check cancellation behaviour: test WooCommerce’s hold-stock setting together with the plugin’s status and expiry logic. Pending and on-hold orders do not necessarily behave alike.
- Verify payment server-side: authenticate callbacks and check order reference, amount, currency, and successful status.
- Prevent duplicate fulfilment: repeated callbacks must update the same transaction safely.
- Reconcile exceptions: handle expired references, missing callbacks, late payments, and refunds explicitly.
Do not mark an order paid merely because the customer reaches a success page. Browser redirects can be interrupted or manipulated; the trusted confirmation must come from the payment system.
Saudi checkout: Mada and Apple Pay
Mada is a practical priority for a Saudi retail checkout, not a feature to infer from generic card support. Confirm explicit Mada acceptance and settlement terms with your gateway. Apple Pay availability also depends on the provider, merchant setup, domain verification, and supported devices.
Test successful payments, declines, cancellations, 3-D Secure authentication, and refunds on real mobile devices. Where required by your courier, collect structured National Address components, including building number, district, postal code, additional number, or short address.
COD, wallets, and bank transfers
For cash on delivery, separate an accepted order from collected funds and courier settlement. Track delivery failures, returned shipments, and collection fees. Phone verification or partial prepayment can help control risk, but should be tested for customer friction.
Confirm gateway support for Egyptian wallets and domestic card schemes individually. If offering bank transfer or InstaPay, use a verified merchant reconciliation workflow; an uploaded screenshot alone is not reliable proof of payment.
Courier integrations can reduce manual entry, but must support your service areas, labels, tracking events, returns, and COD reconciliation. See the guide to e-commerce shipping automation in local markets for the operational handoff.
Building Arabic and RTL WooCommerce storefronts
Arabic support requires translation and layout testing. WordPress and WooCommerce support localisation, but the theme, checkout extensions, emails, and document renderer must also handle right-to-left content correctly.
Test the complete buying journey
- Product grids, sale badges, filters, pagination, and navigation.
- Product galleries, variations, quantity controls, and stock messages.
- Cart totals, coupon fields, delivery options, and validation errors.
- Checkout fields, gateway redirects, and payment references.
- Account pages, order details, and refund messages.
- Transactional emails, invoices, packing slips, and SMS.
Use CSS logical properties such as margin-inline-start and text-align: start where appropriate. Keep phone numbers, references, and mixed-script identifiers readable through deliberate direction handling rather than mirroring every element.
Choose a font with proper Arabic support and test line heights on mobile. Email templates need their own direction and alignment rules. PDF generation needs an Arabic-capable renderer that correctly joins and shapes letters; browser rendering is not a valid PDF test.
Translation architecture and language URLs
WPML, Polylang with its WooCommerce integration, and TranslatePress are options to evaluate. Compare product and variation handling, translated slugs, checkout compatibility, editorial workflow, and performance using a representative catalogue rather than a fixed SKU threshold.
Language subdirectories such as /ar/ and /en/ make a clear structure. Each indexable translated page should normally have a self-referencing canonical and reciprocal hreflang links to its actual equivalents. An x-default annotation is optional and useful for a fallback or language-selector page.
Use ar-EG and ar-SA when pages genuinely target different markets; use ar when a shared Arabic version is appropriate. Follow Google’s guidance on localised versions and the practical guide to multilingual SEO and hreflang implementation.
Translate product information, delivery conditions, returns, and payment instructions—not just interface labels. Arabic keyword research should reflect how customers actually describe products, including common mixed Arabic and Latin searches.
Keeping WooCommerce fast, secure, and indexable
Size hosting for concurrent shoppers, catalogue queries, background jobs, and checkout traffic—not order count alone. Use appropriately sized images, a CDN, and carefully configured caching. Keep cart, checkout, account pages, and personalised responses out of shared full-page caches.
High-Performance Order Storage uses dedicated order tables and can improve order operations. Check extension compatibility before enabling or migrating it. It does not replace product-query optimisation, efficient search, or load testing.
Assign responsibility for updates, monitor security advisories, and apply critical fixes promptly. Test routine changes on staging, require two-factor authentication for privileged users, remove unused extensions, and keep off-server backups with tested restores. Backup frequency should reflect how many orders you can afford to lose.
Indexation checks for bilingual stores
- Check crawl access: important pages should return HTTP 200, avoid unintended noindex directives, and remain accessible to search crawlers.
- Inspect canonicals: translated pages should not all canonicalise to the English version or homepage.
- Control filters: index selected useful facet pages; manage low-value combinations deliberately. Blocking a URL in robots.txt prevents crawlers from seeing its noindex directive.
- Maintain sitemaps: include canonical, indexable URLs and remove redirects, errors, and excluded pages.
- Strengthen internal links: connect categories, products, buying guides, and language equivalents through crawlable links.
- Match structured data to the page: price, currency, availability, and genuine review information should reflect visible content.
- Handle unavailable products deliberately: keep useful temporarily unavailable pages; redirect discontinued products only to close replacements, otherwise use an appropriate removal response.
Use Google Search Console’s Page indexing report and URL Inspection to diagnose exclusions. Better copy can improve usefulness, but a rewrite alone cannot resolve blocked crawling, conflicting canonicals, server errors, or weak site architecture—and does not guarantee indexing.
What to budget for a regional WooCommerce store
The core plugin is free. Total ownership cost includes hosting, implementation, extensions, payment fees, compliance integrations, support, and the staff time needed to keep the systems reconciled.
| Cost area | What to include |
|---|---|
| Infrastructure | Hosting, staging, CDN, backups, monitoring, and recovery |
| Localisation | Translation software, Arabic content, RTL testing, and document templates |
| Payments | Integration, transaction fees, refunds, disputes, and settlement reconciliation |
| E-invoicing | Setup, subscription or document charges, testing, and specification changes |
| Operations | Courier integration, COD reconciliation, maintenance, and security response |
Compare platforms using your actual required features and transaction profile. WooCommerce is not automatically cheaper at high volume, and a hosted platform is not automatically cheaper at low volume. Custom integrations and operational staffing can outweigh subscription differences.
WooCommerce launch checklist for Egypt and Saudi Arabia
- Confirm the seller: identify legal entities, registrations, fulfilment locations, and applicable invoicing obligations.
- Secure payment approval: confirm methods, currencies, settlement, and plugin compatibility.
- Approve the tax model: document price entry, display, tax classes, delivery treatment, and rounding.
- Choose invoice ownership: define issuance triggers, submission flows, retention, and correction procedures.
- Validate catalogue data: check descriptions, variants, Arabic content, item codes, and units.
- Test RTL: cover storefront, checkout, email, PDF, and payment notifications.
- Exercise payment failures: include duplicate callbacks, interrupted authentication, delayed Fawry payments, and expiry.
- Reconcile documents: compare checkout totals, gateway charges, invoices, refunds, and accounting entries.
- Test delivery and returns: verify courier fields, tracking, COD settlement, and return handling.
- Check search access: inspect robots rules, canonicals, hreflang, internal links, sitemaps, and structured data.
- Assign operational owners: name the people responsible for security, payment exceptions, invoice rejections, and recovery.
Launch timing depends on gateway onboarding, product readiness, customisation, and compliance testing. Treat those as project dependencies rather than promising a fixed timeline before they are understood.
Frequently asked questions
Can WooCommerce handle Egyptian and Saudi VAT?
Yes. WooCommerce supports tax rates and classes, including the standard 14% Egyptian and 15% Saudi rates where applicable. You still need to determine the correct treatment for your seller, products, customers, and shipping arrangements.
Do prices have to be entered inclusive of VAT?
No. Internal price entry and customer-facing display are separate settings. You can enter net prices and display gross prices. Configure consumer displays to meet the applicable requirements and keep the entry method consistent with your catalogue data.
Is a WooCommerce PDF invoice enough for ZATCA?
No. A PDF alone does not demonstrate compliance. The solution must meet the requirements applicable to your phase and document type, including structured data and, under Phase 2, the relevant clearance or reporting workflow.
Can I accept Fawry payments through WooCommerce?
Yes, through a supported integration and merchant account. For reference payments, confirm reference delivery, expiry handling, stock reservation, authenticated callbacks, and reconciliation before enabling the method.
Does WooCommerce support Arabic?
Yes. A complete Arabic store also needs an RTL-compatible theme, translated checkout extensions, and tested email and PDF rendering. Test real product names, mixed-script addresses, and payment references.
Can one WooCommerce store serve both countries?
Yes, if its payment, tax, fulfilment, and invoicing architecture supports the operating model. Multiple legal entities may make separate storefronts simpler, but the key requirement is reliable routing to the correct seller and accounting workflow.
Build around the order lifecycle
A reliable regional store keeps four things aligned: what the customer owes, whether payment is confirmed, which invoice or receipt has been issued, and what has been fulfilled. Tax settings, local gateways, Arabic presentation, and courier integrations should support that same lifecycle.
Get those foundations working before expanding acquisition. For later growth planning, consider an affiliate marketing network for MENA merchants with attribution and settlement rules suited to delayed payments and COD. If evaluating a different platform, see how to migrate from WooCommerce to Shopify.
For help scoping a WooCommerce build, local payment integration, or invoicing workflow in Egypt or Saudi Arabia, contact the Aghrba team.