E-commerce architecture

International POD Store
UAE → Worldwide

A practical, scalable setup for BigCommerce, Printful, Printify, CustomCat, Stripe and PayPal. The goal is not to make every system do everything — it is to give each platform one clear job.

BigCommerce = store & customer pricingUSD = internal referenceStripe = primary multi-currency paymentsPrintful = primary fulfillment

1. The simple idea

The store should separate what the customer pays from what the POD supplier charges. Trying to make Printful, Printify and BigCommerce share one currency, one shipping engine and one pricing logic creates unnecessary complexity.

Recommended principle: BigCommerce controls the customer-facing commercial experience. POD providers control production and fulfillment costs.
BigCommerceProducts, retail prices, promotions, checkout and commercial shipping rules.
Stripe / PayPalCustomer payment and settlement.
Printful / Printify / CustomCatProduction, fulfillment and tracking.

2. Recommended architecture

Customer
UAE / Europe / UK / USA / Worldwide
→
BigCommerce
Store, prices, currency, checkout & shipping rules
→
Stripe / PayPal
Customer payment in the supported checkout currency
Order
Stable BigCommerce order + master SKU
→
Fulfillment decision
Normally Printful; Printify/CustomCat when appropriate
→
POD provider
Production + shipping + tracking
Why this works: the customer can pay in AED, EUR, GBP or USD without forcing the POD providers to price or bill the order in AED.

3. Currency strategy

LayerRecommended setupReason
BigCommerce base currencyUSDClean common reference for POD costs, product economics and international pricing.
Internal pricing modelUSDOne reference point for cost, margin and profitability calculations.
Customer currenciesAED / USD / EUR / GBPUse local or familiar currencies where commercially useful.
PrintfulUSD billing referenceKeep supplier-side economics consistent with the internal pricing model.
PrintifyUSD billing referenceKeep provider economics separate from customer presentation.
CustomCatUSDSimple and consistent supplier-side accounting.
Important distinction: a price being displayed in AED does not automatically mean the payment is processed in AED. BigCommerce distinguishes display currency from transactional currency. This must be tested with the selected payment setup.

We want to avoid a chain such as USD → AED → USD → EUR. The store should determine the customer's checkout currency once; the payment provider then handles settlement or any required conversion.

4. Why USD should remain the internal reference

What USD doesIt gives the business one consistent language for supplier costs, margins, comparisons and profitability.
What USD does not doIt does not mean UAE customers must see or pay in USD.
A UAE-based company does not need AED to be the internal POD pricing currency. AED is the customer-facing market currency for UAE; USD is the operational reference currency.

5. Product pricing: where the price should live

DataSystem of recordRule
Production costPOD providerUse as a cost input, not as the customer price.
Shipping cost to businessPOD providerUse as a cost input / reserve.
Retail priceBigCommerceCommercial source of truth.
Sale price / discountsBigCommerceKeep promotions under one commercial system.
Do not use “supplier cost × 1.5” as the pricing strategy. It ignores shipping differences, payment fees, FX, promotions and the reserve needed for reprints/refunds.

A practical pricing logic

Sale Price ≈ (production cost + expected shipping absorbed + payment/fraud reserve + returns/reprint reserve + other variable costs) ÷ (1 − target margin)

Taxes collected from the customer should be treated separately from operating margin. Exact tax treatment should be confirmed for each market and fulfillment model.

6. Why shipping is the hardest part

A T-shirt, a mug and a poster do not behave like the same shipping product. Their supplier costs and delivery economics can be very different by destination.

What we should not assumePrintful or Printify automatically sends every live supplier shipping quote into BigCommerce and calculates the exact combined cost of any mixed cart.
What we should do insteadStart with simple commercial shipping rules: zones + product classes + free shipping where the economics make sense, with special handling for high-cost or bulky products.

Recommended starting model

Product familyCustomer shipping modelWhy
T-shirts / hoodies / sweatshirtsFree shippingShipping cost is partly absorbed into product pricing, creating a simple customer experience.
MugsSeparate / class-based shippingShipping can be disproportionately high compared with product price.
Posters / wall artSeparate / class-based shippingDifferent packaging, dimensions and delivery economics.
Mixed cart example: a customer buys one T-shirt and one mug. The order remains one BigCommerce order, while the physical items may travel in separate shipments. The customer should see one clear commercial shipping charge rather than internal supplier calculations.

7. Multi-provider strategy: Printful + Printify + CustomCat

Printful — PrimaryMain provider for standard products and the preferred production path.
Printify — Backup / AlternativeUseful when price, availability, provider location or delivery performance is better.
CustomCat — SpecialistUse only where it has a clear product or cost advantage.

What the native integrations do not provide

The native connections do not create one universal decision engine saying: “If Printful is more expensive today, automatically send the order to Printify.” Each provider manages its own integration and fulfillment workflow.

Therefore: automatic cross-provider routing is a separate capability. It requires custom logic, middleware and/or APIs when the business becomes large enough to justify it.

The safe SKU strategy

Keep one permanent BigCommerce master SKU. Example: DR-TSH-001-BLK-M

That SKU can map internally to a Printful variant, a Printify variant and, if needed, a CustomCat variant. Switching the fulfillment provider should not require changing the customer-facing BigCommerce SKU.

8. Order-level fallback: the practical version

This is the safe pre-automation workflow when the same product can be fulfilled by more than one provider.

1
Customer places the order in BigCommerce.The commercial order stays in BigCommerce with the same SKU.
2
Printful receives the order as a draft / pending confirmation.Auto-confirmation should be disabled while manual provider selection is part of the workflow.
3
Compare the available fulfillment options.Check cost, availability and delivery suitability.
4
If Printful is best, confirm Printful.
5
If Printify is better, do not confirm Printful.Use Printify's manual import / unsynced-order workflow for that specific order.
Key point: provider choice is an internal fulfillment decision. The customer-facing BigCommerce product and SKU do not need to change.

This manual fallback is intentionally different from permanently migrating the product variant to Printify. A permanent mapping can change the behavior of future orders and should only be done intentionally.

9. Stripe and PayPal

Stripe — PrimaryUse Stripe as the main multi-currency payment infrastructure for BigCommerce. The intended model is to let customers pay in supported transactional currencies when configured.
PayPal — SecondaryOffer PayPal as an alternative payment method, but do not make the overall architecture dependent on PayPal being equivalent to Stripe for every BigCommerce multi-currency scenario.
Customer
AED / USD / EUR / GBP where available
→
BigCommerce
Creates the order in the checkout currency
→
Payment provider
Processes payment and settles according to account configuration
Avoid double conversion. Do not independently convert the customer price and then ask the payment provider to convert that result again before the customer is charged. The customer-facing transaction currency should be deliberate and tested.

10. What we deliberately do NOT do

Do notWhyBetter approach
Use AED as the supplier-side POD currencyPOD billing and cost systems are not designed around AED.Keep supplier economics in USD and present AED at the storefront.
Let Printful markup control the final retail priceIt does not reflect the complete business cost structure.Calculate price centrally and publish the retail price in BigCommerce.
Expect live Printful shipping rates to flow automatically into BigCommerceThe native integration does not provide a universal live rate engine.Use commercial shipping rules first; add a custom engine only later if justified.
Change the BigCommerce SKU when switching providersProvider mappings can become disconnected and future sync can break.Keep a stable master SKU and change only the fulfillment path.
Auto-fulfill through both Printful and PrintifyIt creates a serious risk of duplicate production.One active fulfillment path per order; use manual fallback until routing is automated.
Build custom middleware on day oneIt adds cost and maintenance before there is enough operational volume.Start simple and introduce automation when manual decisions become material.

11. How the architecture scales

20–100 productsNative integrations + stable SKUs + central pricing + simple shipping rules. No middleware required.
100–300 productsAdd a central pricing / SKU / provider table and monitoring for cost changes and low-margin products.
300+ products or high order volumeConsider an order router / middleware when provider choice, shipping logic or manual intervention becomes too time-consuming.
The real trigger for automation is not the number of products alone. A store with 500 products and few orders may remain simple; a store with 80 products and hundreds of monthly orders may already benefit from automation.

12. Recommended setup — in plain English

Commerce

BigCommerce is the central store. USD is the internal reference currency. AED, EUR and GBP are customer-facing currencies alongside USD.

Pricing

Prices are calculated from real business costs and controlled in BigCommerce. Supplier markups are not the pricing authority.

Shipping

Start with a small number of geographic zones and product shipping classes. Use free shipping where the product economics support it.

Fulfillment

Printful is the primary provider. Printify is a practical fallback or alternative. CustomCat is reserved for selected products.

Order control

Keep Printful auto-confirmation off while the team wants the option to compare providers. Keep the BigCommerce SKU unchanged when switching fulfillment.

Payments

Stripe is the primary multi-currency payment layer. PayPal is a secondary payment option.

13. Final recommendation

If we were building the store today: BigCommerce would be the commercial source of truth, USD would be the internal reference currency, AED/USD/EUR/GBP would be the initial customer currencies, Stripe would be the primary payment gateway, Printful would be the default fulfillment provider, Printify would be a controlled fallback, and CustomCat would remain a specialist provider.

The architecture deliberately avoids trying to make the POD providers control customer pricing, customer currency and customer shipping. Their job is production. BigCommerce's job is commerce. Stripe's job is payment. This separation keeps the system understandable, reduces synchronization risk and gives us a clean path to automation later.

The architecture is intentionally simple at launch, but it is not a dead end. The same master SKU, pricing model and provider mapping can later feed a custom order-routing layer when automation creates a real operational benefit.

Prepared as a practical architecture brief for an international UAE-based POD e-commerce business. Platform capabilities and commercial/tax rules should be re-checked when the store is implemented and before going live.