Shopify app types and which one you need

Once you have decided that Shopify needs to talk to your accounting system, there is a structural choice about what does the talking. It gets made casually, often by whoever is available, and it has consequences that surface years later.

The three routes

A public app — something listed in Shopify's app store, built to serve many merchants, installed through a standard flow. It has been reviewed by Shopify, it is versioned and maintained by its vendor, and its permissions are declared up front.

A custom app — created for one store, typically through the store's own admin or a partner account, not listed publicly and not reviewed. It gets an access token and the permissions you grant it, and it can do everything a public app can within your store.

A script or automation somebody wrote — technically a custom app underneath, but worth separating because the difference is not technical. A custom app built by a vendor with a support obligation is a product. A script written by a developer who has since moved on is a liability with a login.

When a custom app is the right answer

It genuinely often is, and this is not a recommendation against it.

Your requirement is specific to you. A join between Shopify and an internal system nobody else has. A public app cannot serve that and does not try.

You have the capability in-house. Somebody who will still be there next year, and who will handle the quarterly API version cycle — see Shopify API versioning and what breaks.

You need permissions a public app would not request. Narrow, unusual access that makes sense for one business.

One store, no plans for more. A custom app is scoped to a store, so a second store means a second app and a second set of credentials.

When a public app is the right answer

Also often, and for reasons that have little to do with the code.

Somebody else carries the maintenance. The quarterly upgrades, the deprecated fields, the retirement deadlines. This is the largest hidden cost in the whole area and transferring it is worth real money.

It has been reviewed. Not a guarantee of quality, and a floor.

It has been run against many stores. Which means the edge cases — a partial refund on a discounted order, a chargeback on an order beyond the historical window, a duplicate notification during an outage — have been encountered and handled, rather than waiting to be discovered on yours.

It survives your team changing. The most underrated point. An integration nobody currently at the company built is fine if a vendor maintains it and dangerous if not.

That last point is the one to weigh honestly. The question is not whether your developer can build it. It is what happens when they are not there — see why integration depth beats feature count.

The thing both routes have to get right

Whichever you choose, the same technical obligations apply, and they are the substance of the work.

Authentication and secure credential storage. Handling the request budget without being throttled — see Shopify API rate limits and query cost. Verifying notification signatures, and making handlers idempotent because duplicates are normal — see Shopify webhooks and why they are not enough. A periodic reconciling pull so a missed notification is detected rather than silently lost. Version pinning and a quarterly upgrade cycle. Reading discounts, tax and refunds at the level Shopify recorded them rather than deriving them — see Shopify discounts, taxes and line-level allocation.

That list is the same regardless of route. What differs is who is responsible for it in eighteen months.

The question that decides it for most Malaysian merchants

There is a specific consideration here that changes the calculation, and it is not about Shopify at all.

Because Shopify Payments is unavailable in Malaysia, the money side of your reconciliation does not come from Shopify. It comes from your payment gateway, on its own schedule, in its own format, with its own reference scheme — see the Shopify third-party gateway fee explained.

So a Shopify integration alone does not reconcile a Malaysian store. It gives you orders. You still need the gateway settlement and the bank statement joined to them, which is a three-way match rather than a two-way one — see how Shopify reconciliation actually works.

That reframes the build decision. The Shopify connector is the smaller half of the problem, and a custom app that reads Shopify beautifully and stops there has solved the part that was already easiest. What matters is whether the whole chain is covered, and by whom.

Common questions

What is the difference between a public and a custom Shopify app?

A public app is listed in Shopify's app store, reviewed, built for many merchants and maintained by its vendor with declared permissions. A custom app is created for a single store, is not listed or reviewed, and receives an access token with whatever permissions the merchant grants. Technically they can do the same things within a store; the difference is who maintains it.

When is a custom Shopify app the right choice?

When the requirement is genuinely specific to your business, you have in-house capability that will still be there next year to handle the quarterly API version cycle, or you need narrow permissions a public app would not request. It suits a single store, since a custom app is scoped to one and a second store means a second app and second set of credentials.

What is the biggest hidden cost of building your own integration?

Ongoing API maintenance. Shopify releases quarterly and retires older versions on a published schedule, so somebody has to review changes affecting the fields you use, test against the release candidate and migrate before retirement — indefinitely. Using a maintained app transfers that obligation, which matters more than the difficulty of the initial build.

Does a Shopify integration alone reconcile a Malaysian store?

No. Because Shopify Payments is not available in Malaysia, the money side comes from a separate payment gateway with its own schedule, format and reference scheme. A Shopify connector supplies the orders, and the reconciliation still requires the gateway settlement and the bank statement joined to them, making it a three-way match rather than a two-way one.

Related: what it takes to build a Shopify connector · Shopify API versioning and what breaks · how Shopify reconciliation actually works