Shopify Payments
Card transactions recorded against the order, with payouts imported as a batch net of Shopify fees so the bank line matches cleanly.
A Shopify store usually collects through more than one route: Shopify Payments for cards, a local gateway for UPI or net banking, PayPal for overseas buyers, and cash on delivery for everyone else. Each one reaches your bank differently.
This page is about that half of the problem. The catalogue and order side is covered on Odoo Shopify integration; what follows is how the money gets accounted for.
Businesses running Odoo with OdooBots
Shopify payment gateway integration makes every route a customer can pay by reconcile against the right Odoo invoice. Shopify Payments payouts arrive as a batch net of fees and match the orders behind them, third-party gateway transactions carry their own reference, cash on delivery is held until the courier remits, failed and pending payments stay visible, and refunds and chargebacks post against the original order.
Cash on delivery is where storefront accounting most often breaks. The order is paid in Shopify long before the money exists, and treating it as received overstates both revenue and cash.
Six payment routes can run through one storefront, and each reaches your bank on its own schedule.
Card transactions recorded against the order, with payouts imported as a batch net of Shopify fees so the bank line matches cleanly.
Razorpay, PayPal or any other gateway used at checkout, each carrying its own reference and its own settlement behaviour.
COD orders held as receivable from the courier until remittance arrives, net of their charge, rather than treated as paid at checkout.
Full and partial refunds raising credit notes, with the fee treatment and the effect on the next payout handled explicitly.
Reversals posted against the original order so a debit weeks after delivery has a traceable cause.
Authorisations that never captured and payments stuck pending visible in a queue, because these are lost orders rather than technical noise.
A card order is paid at checkout and the transaction attaches to the invoice. Shopify pays out a few days later as one deposit covering many orders, less its fee, and that deposit reconciles against the batch. A COD order is marked paid in Shopify but is really a receivable from the courier until they remit, net of their charge. A gateway order carries that provider’s reference and settles on that provider’s cycle.
Treating all of them as cash received on the day of the order is the single most common reason a storefront’s books disagree with its bank.
These are the decisions that are cheap to make now and painful to reverse once two systems have been exchanging records for a month.
Every gateway, wallet and COD option available at your checkout, listed before anything is configured, because each settles differently.
Held as receivable from the courier until remittance, net of their charge. Treating it as paid at checkout overstates both revenue and cash.
How a Shopify Payments deposit is matched to the orders it covers and where the fee posts.
Shopify fees, gateway commission and courier COD charges each have their own account and their own GST treatment.
What a reversal does to the books when it lands weeks after delivery, agreed in advance.
How a partial refund affects the invoice, the fee and the next payout, since all three move.
A named owner for authorisations that never captured, because those are orders you could still save.
We would rather say this before you buy licences than after. These are the areas where we scope real development, recommend a different tool, or tell you the connector will not reach.
Which gateways appear at checkout is set in Shopify. Odoo records what was collected; it does not configure the storefront.
Fighting a chargeback happens with the provider. Odoo records the outcome and its accounting effect.
Buy-now-pay-later routes settle on their own terms and need their own mapping rather than sharing the card flow.
Every courier reports COD collections differently, so each one is its own import and matching rule.
Payouts in a currency other than your books add conversion handling to the reconciliation.
Importing past payouts is rarely worth it. A clean cut-off date usually is.
Connecting Shopify Payment Gateway to Odoo is less about the connector than about agreeing what is true where, and what happens when a record will not go through.
Understand every payment route at your checkout, your COD share, which couriers remit to you, and how payouts are reconciled today.
Agree the treatment of each route, where every fee posts and how payouts and COD remittances reconcile, before anything is connected.
Connect Shopify Payment Gateway to Odoo using the standard connector where one fits, and build only what the connector genuinely cannot reach. See Odoo customization.
Your records, in a test database, including the awkward ones — the cancelled order, the partial refund, the product that exists on one side only.
A queue for failed records with a named owner and an alert, because an integration nobody watches diverges quietly and the divergence is found at audit.
Cutover with a reconciliation on both sides, then hypercare, then ongoing support and AMC.
We do not publish one integration price, because the same connector costs very differently depending on the factors below. We do publish what moves the number, and the price is fixed in writing before work starts.
We treat cash on delivery as what it is — money the courier owes you — rather than as paid at checkout. For Indian storefronts that single decision is usually the difference between books that reconcile and books that do not.
Product capabilities stated on this page are documented by Odoo. The mapping advice, failure handling and limitations come from our own integrations.
Tell us what share of your orders are cash on delivery and which gateways you run at checkout. Those two answers shape the configuration, and the diagnosis call is free.