Provider packages

The vendor integrations a store plugs in — a payment gateway, a courier, an SMS sender, a phone-risk check — are shared, versioned packages, not code you write per store. You select which provider to use, as data; the package itself is upgraded by version. Swapping Pathao → Steadfast, or adding a gateway, is a configuration change, never a code edit.

The packages

Capability	Configure it at	Adapters shipped today
Payment gateway	Payment providers	SSLCommerz, Stripe (plus built-in Cash on Delivery)
Courier / shipping	Courier providers	Pathao, Steadfast, RedX
Transactional SMS	SMS provider	Twilio, a BD local gateway
COD phone risk	Phone-risk provider	BDCourier, CourierInsights

Each package is independently versioned and installed via the deployment’s Python requirements — upgrading one is a version bump and a redeploy, not a patch to your store’s code (see Upgrading).

The pattern is the same in every package

1. A base interface defines the canonical capability — create a consignment, fetch a label, parse a webhook; send an SMS; check a phone’s risk. Every adapter maps its vendor’s quirks onto that one shape, so vendor-specific status strings become one canonical status your store reads consistently.
2. A factory builds the right adapter by name from a credentials record.
3. A platform service resolves which provider is active for a store and loads its credentials, then delegates — see Platform → Integrations & credentials.

So the call site your store’s checkout or fulfilment logic hits is provider-agnostic: swapping the vendor changes only configuration.

How a provider is selected

In order:

1. The store’s own selection (its tenant config).
2. A deployment-wide default (an env var, e.g. COURIER_DEFAULT_PROVIDER).
3. Otherwise, the first provider that has credentials configured.

Credentials never live in config

Vendor API keys and secrets live only in the encrypted Integrations store, never in the tenant config and never in .env alongside your other settings. The public config endpoint only ever names which provider is active — never its secret. See each provider page for exactly where to enter credentials.

Vendor-neutral policy stays out of the adapter

Where a package makes a judgement call — e.g. what counts as “high risk” in the fraud package — that logic is one shared, vendor-independent function, not duplicated per adapter. Swapping the vendor never changes what the judgement means.

Adding a provider your deployment needs

If a vendor you need isn’t in the table above, that’s a package change, not a per-store hack: a new adapter is added to the relevant package, registered in its factory, and shipped by version. Talk to your Nudova contact (or, if you’re an agency running your own fork, your engineering team) about adding an adapter — see the Courier providers and Payment providers pages for what’s shipped today.

Related: Payment providers · Courier providers · SMS provider · Phone-risk provider · Upgrading.