```json
{
    "title": "ERPNext Integrations Explained: Connecting Payment Gateways, Marketplaces and Shipping",
    "url": "https://aavatto.com/blog/erpnext-integrations-payment-gateways-marketplaces-shipping/",
    "datePublished": "2026-10-06",
    "dateModified": "2026-10-19",
    "language": "en-US",
    "description": "See how ERPNext integrations connect payment gateways, marketplaces, and shipping carriers through its REST API — and when you need custom work.",
    "author": "Aavatto",
    "publisher": "Aavatto - Frappe & ERPNext Experts | Custom Development, Implementation & Support"
}
```

# ERPNext Integrations Explained: Connecting Payment Gateways, Marketplaces and Shipping

ERPNext integrations connect the system to the payment gateways, e-commerce marketplaces, and shipping carriers a business already uses, so orders, payments, and fulfillment data flow into ERPNext automatically. Some connections are ready-made apps; others require custom work against ERPNext's REST API, depending on how standard your setup is.

That distinction — native app versus custom build — is the question most guides skip, and it's usually the one that matters most once you're past "does ERPNext support X" and into "how much work is this actually going to be."

## How ERPNext integrations work under the hood

Every record type in ERPNext — a Sales Order, a Payment Entry, an Item — is called a Doctype, and every Doctype is automatically exposed as a REST API endpoint with standard create, read, update, and delete operations, filtering, and pagination. That's the foundation everything else sits on, and it's why what's often called ERPNext API integration in practice is really just building against that same underlying interface. It's also why ERPNext integrations tend to be more flexible than integrations built against a closed SaaS platform: if a native connector doesn't exist or doesn't do what you need, there's a documented API underneath it to build against, rather than a locked box.

On top of that API, integrations show up in ERPNext in three forms:

**Native, built into ERPNext core** — configured through Settings, no separate app needed.

**Community or Frappe-maintained apps** — separate installable apps that add a connector, usually for a specific platform or region.

**Custom REST/webhook integrations** — built for a business's specific combination of systems, versions, and workflows.

Most businesses end up using all three at once: a native payment gateway, a community app for their marketplace, and a custom webhook for the one system that doesn't have off-the-shelf support.

## Payment gateway integrations

ERPNext ships with native support for several payment gateways, including PayPal, Razorpay, Stripe, Braintree, and GoCardless, configurable directly from Settings without custom development. Once connected, payments and refunds post into ERPNext automatically — a Sales Invoice gets marked paid, a Payment Entry gets created, and the ledger stays current without someone manually matching bank statements to invoices.

Where this gets more complicated: businesses running region-specific gateways (a local Indian payment aggregator, a Gulf-based provider, a bank-specific plugin) or subscription/recurring billing logic that doesn't map cleanly to ERPNext's standard invoice-payment cycle. In those cases the native connector either doesn't exist or only covers the simple case, and the gap gets filled with a custom integration against the payment provider's API and ERPNext's REST API — reconciling webhooks, handling partial payments, and mapping currency or tax logic specific to how that business actually invoices.

## Marketplace and e-commerce integrations

For e-commerce, ERPNext's REST API makes it possible to connect to essentially any marketplace or storefront platform, and there are existing apps and connectors for common ones — Shopify and WooCommerce are the most frequently used, with orders, inventory levels, and customer records syncing back into ERPNext.

Amazon and larger multi-channel marketplaces are a different story. There's no single native ERPNext-to-Amazon connector that handles every seller scenario cleanly, because Amazon's own API varies by marketplace region, order type, and fulfillment method (FBA versus self-fulfilled). Businesses selling across several marketplaces at once — their own Shopify store plus Amazon plus a regional marketplace — usually need a custom sync layer that reconciles inventory across all of them in near real time, so a sale on one channel correctly decrements stock everywhere else before it's oversold. That reconciliation logic is almost never a native feature; it's built.

## Shipping integrations and logistics integrations

On the shipping side, ERPNext's Shipping app integrates with rate-comparison and label-generation providers, letting a business compare courier rates and generate shipping labels from within ERPNext rather than switching to a separate portal. For businesses in India, connectors to aggregator platforms extend this to a wider set of local couriers.

The common failure point here isn't the initial connection — it's tracking status sync. A shipment gets created, but delivery status, exceptions (failed delivery, return-to-origin), and proof-of-delivery updates don't always flow back into ERPNext automatically unless that webhook path is specifically built and tested. For a business shipping a few dozen orders a week, checking status manually is tolerable. For one shipping hundreds of orders a day across multiple couriers, that gap turns into a support team manually checking tracking pages — usually the point a business decides the custom webhook integration is worth building.

Talk to us about your integration if you're already past the point where a native connector covers what you need — our integrations and API development team builds the custom REST and webhook work that native apps don't reach, for payment gateways, marketplaces, and shipping carriers alike.

## Native app vs. custom integration: how to decide

A short framework, since this is the actual decision most readers are trying to make:

SignalNative/community app is probably enoughCustom integration is probably neededPlatformMajor, widely-used (Shopify, Razorpay, Stripe)Regional, niche, or legacy systemVolumeLow-to-moderate order/transaction volumeHigh volume where sync delays or errors compoundWorkflowStandard invoice-payment or order-fulfillment cycleCustom pricing, subscription billing, multi-channel inventory reconciliationStatus trackingBasic connection is sufficientReal-time status/exception sync requiredSystems involvedOne platform per integrationMultiple systems needing to reconcile with each other

If most of your answers land in the left column, start with the native or community option and revisit later if it doesn't scale. If several land in the right column, it's worth scoping the custom build early rather than discovering the gaps after go-live.

## Frequently Asked Questions

[Does ERPNext integrate with Shopify and WooCommerce out of the box?](#collapse-1301)

Yes — both have existing apps/connectors that sync orders, inventory, and customers, though the depth of what syncs (returns, partial refunds, multi-currency) can vary and sometimes needs custom adjustment for a specific store's setup.

[What payment gateways work with ERPNext natively?](#collapse-1302)

PayPal, Razorpay, Stripe, Braintree, and GoCardless are supported natively through Settings. Regional or niche gateways typically require a custom integration against the gateway's API.

[Can ERPNext connect to any shipping carrier?](#collapse-1303)

Through its Shipping app and available connectors, ERPNext reaches a wide range of couriers, especially in India via aggregator platforms. Full status and exception tracking back into ERPNext, however, often needs custom webhook work.

[Do I need a developer to set up ERPNext integrations?](#collapse-1304)

For native, Settings-based connections (most payment gateways, Shopify, WooCommerce), no — configuration is usually enough. For custom systems, high-volume multi-channel setups, or anything requiring status sync, yes, you'll need development work against ERPNext's REST API.

[How does ERPNext's API actually work?](#collapse-1305)

Every Doctype is exposed as a REST endpoint supporting standard CRUD operations, authentication, and filtering — which is what any native app, community app, or custom integration is built on top of.

Most integration questions come down to the same thing: is this a standard connection someone has already built, or does your setup have enough volume, complexity, or non-standard systems that it needs to be built for you specifically. If you're not sure which side of that line you're on, [talk to us about your integration](/services/integrations-api-development/) and we'll help you scope it before you commit engineering time either way.