How to Auto-Tag Shopify Orders by Payment Gateway

Yes — the payment gateway an order was paid through is visible on that order's own detail page, and it's included as a column in Shopify's CSV order exports too, so the raw data genuinely exists and is accurate. What's missing is a tag: nothing about the gateway is stamped onto the order in a form a saved search, a packing-slip app, or a fulfillment tool can filter by. A staff member scanning the order list for manual-payment orders that need a follow-up before they ship has to open each order individually to check, or export the whole list and filter it in a spreadsheet, neither of which scales past a small handful of orders a day. The information is correct and available; it just isn't available in the one place, a tag, that most downstream tools actually know how to read.

Partially, and it's worth understanding exactly where it stops. Flow can check an order's payment gateway on an order-created trigger and apply an action, including adding a tag, the moment a new order comes in. Where it falls short is scale and history: each gateway, or each list of gateways you want grouped together, needs its own separate workflow built and maintained, so three manual-style gateways means three workflows rather than one rule with a list. And Flow only ever reacts going forward — it has no built-in way to catch up on orders placed before the workflow existed, so turning one on today gives you a tag on tomorrow's orders but nothing on the months of order history you already have, which is exactly the data a report or reconciliation process usually needs most.

Yes — a single rule can match against a list of gateways rather than just one, so Bank Deposit and Cash on Delivery orders both land the same 'manual-payment' tag from one rule, with no need to build and maintain two nearly-identical ones side by side. That matters beyond just convenience: if your fulfillment process treats every unpaid-at-order-time gateway the same way — hold until payment confirms, notify the customer, whatever the actual workflow is — then one combined tag is a more accurate description of your process than two separate tags a downstream tool would have to check for individually. If you ever add a third manual gateway later, extending coverage is a one-line edit to the existing list, not a new rule built from scratch and wired into every place the old ones were already being checked.

No. The tag describes a fact about how that specific order was actually paid at the time it was placed, and that fact is permanent — removing a gateway from checkout going forward doesn't retroactively change how an order six months ago was paid for. Historical orders keep whatever tag correctly describes them, and that's exactly what you want if the tag feeds a report or reconciliation process: 'orders paid by Bank Deposit last quarter' should still return every order that was genuinely paid that way, even after Bank Deposit itself is no longer offered at checkout. The only practical change is that no new orders will produce that tag going forward, since the rule simply stops matching anything from that point on, rather than needing to be deleted or edited — you can safely leave the rule in place indefinitely, even years after you've stopped offering that particular gateway at checkout.