How an order is recorded in Salesforce

Use this article to read a StoreConnect order in Salesforce: which records checkout creates, what each figure on them means, and which date to use when you reconcile orders against a payment provider’s payouts. It is for administrators building reports and Flows on order data, and for finance staff matching Salesforce to their payment provider.

The records checkout creates

Checkout writes one Order and the records that hang off it. The Order is the standard Salesforce object; the others are StoreConnect objects or standard objects that StoreConnect extends.

Record	Object	One per	What it holds
Order	Order	checkout	Customer, store, status, checkout step, totals and dates
Order Product	OrderItem	line on the order	A product the customer bought, or a charge such as shipping or a promotion (see below)
Order Item Tax	Order Item Tax	tax rate on a line	The tax charged on that line at that rate
Payment	s_c__Payment__c	transaction	An amount taken (or refunded), with the provider’s transaction reference
Payment Item	s_c__Payment_Item__c	order product covered by a payment	How much of the payment applies to that line
Order Campaign	Order Campaign	UTM set on the visit	Marketing attribution, when UTM tracking captured any

The Order is created during checkout, before payment is captured, with Status Draft. The order products are written in the same transaction, so the whole set appears together. The Checkout Step ends in -syncing until payment finalizes, then in -finalized while the records sync to Salesforce. Build automations on Checkout Step reaching complete, not on order creation; see About order checkout steps.

What the order totals mean

Total Amount on the Order is the standard Salesforce roll-up of every order product’s Total Price (Unit Price × Quantity). StoreConnect stores every Unit Price tax-inclusive, even on a tax-exclusive price book, so Total Amount is the amount the customer was asked to pay: products, shipping, any promotion reduction and any payment surcharge, including tax.

Total Taxes (s_c__Total_Tax_Amount__c) is the tax portion of that total, kept up to date as the order changes. Each order product also carries its own Tax Amount, and one Order Item Tax record per tax rate that applied to it.

Total Points Amount and Total Earn Points Amount hold loyalty points spent and earned on the order, when you use loyalty points.

The lines on an order

Every line is an Order Product. What it represents depends on the product on the line.

Line	Product on the line	Notes
A purchased product	The product the customer bought	Unit Price is the sale price per unit. Any per-unit reduction, from a sale price or a promotion’s share, is recorded in Unit Discount, and the line total of reductions in Total of Discounts (see Discounts)
Shipping	StoreConnect Shipping	Added when the customer chose a shipping method. The method they chose is in Shipping Method Selected at Checkout on the order
Promotion code	StoreConnect Promotion	One negative line totaling the reduction from the promo code (see Promotions)
Payment surcharge	Your surcharge product	Added when payment is taken with a provider that has a surcharge configured
Cash rounding	StoreConnect Cash Rounding	POS cash sales rounded to the nearest denomination
Tip	StoreConnect Tipping	Added when a customer adds a tip

The StoreConnect products are reserved products installed with the package. Do not edit or delete them.

A deposit does not create a separate line. The deposit taken at checkout is recorded in Deposit Amount on the order product and Checkout Deposit Amount on the order; the balance is collected later as another payment.

Payments and “amount paid”

Each time money moves, StoreConnect creates a Payment (s_c__Payment__c) related to the order:

Field	Meaning
Amount (s_c__Amount__c)	The amount of this transaction, including any surcharge. Negative for a refund
Status (s_c__Status__c)	success once settled; pending for providers that settle later, such as ACH; failed; and the preauthorization states preauthorized, confirm_preauthorization, cancel_preauthorization, partial_capture and released. Refunds taken through the API also write refund_pending or pending_approval, which are not in the packaged picklist
Origin (s_c__Origin__c)	Where the payment came from: WC01 a one-off web purchase, WS01 a web purchase containing a subscription, SF01 taken in Salesforce, PO01 POS, SU01/SU02 subscription renewals, and so on. See Payment origin codes
Method (s_c__Method__c)	The payment provider that took it, for example Stripe
Transaction Number (s_c__Transaction_Number__c)	The provider’s transaction reference. On a pay-on-account order it is the PO number the customer entered, stored with a PO# prefix, for example PO# 12345
Paid At (s_c__Paid_At__c)	When the provider confirmed the payment
Surcharge Amount (s_c__Surcharge_Amount__c)	The surcharge portion of Amount, if any

StoreConnect does not add an “amount paid” field to the Order. The amount paid is the sum of Amount across the order’s Payment records with Status success. Build it as a report summary, or as a Flow that sums the payments and writes the result to a custom field on the order. Leave pending payments out until they succeed.

Under each Payment, a Payment Item records how much of the payment applies to each line. Product, shipping and surcharge lines are all covered, in proportion to each line’s share of the total payable.

Two kinds of line are handled differently. A promotion line gets no payment item, because no money was collected against it; the reduction shows as a smaller amount on the product line instead. On a POS sale, a StoreConnect Tipping line, and a StoreConnect Cash Rounding line on a cash payment, do get a payment item, recorded at the exact amount of the line rather than as a proportional share. For the exact fields written, see Taking order payments from Salesforce.

A refund is a negative Payment. For web orders the documented process is to record the refund on a separate refund order rather than on the original; see Process refunds for web orders. A refund raised through the API behaves differently: it creates a negative Payment on the original order, linked to the payment it reverses.

Which date to use

An order carries three dates that are easy to confuse. They are set once, when the order is created, and are not changed by later edits or payments.

Field	Type	What it is
Created Date (CreatedDate)	Date/time, UTC	When the record was created in Salesforce. This is a few seconds after checkout, once the sync has written the order
Submitted Date (s_c__Submitted_Date__c)	Date/time, UTC	When the customer completed checkout. For a POS sale it is the time on the register when the sale was made, including sales made offline and synced later
Order Start Date (EffectiveDate)	Date	The calendar date of the sale in the store’s Default Timezone (on the Store record) at the moment the order was created

Order Start Date is a date, not a timestamp, and it is worked out in the store’s timezone, so it can be a day earlier or later than the date part of Created Date, which is in UTC. A store in a UTC-5 timezone that takes an order at 02:43 UTC on 5 February records Order Start Date as 4 February, because it was 21:43 on 4 February for the store. One other case to know: a POS sale made offline gets the date it reached the server, while Submitted Date keeps the time of the sale.

Which field to use:

• Daily sales in the store’s local day: Order Start Date. Set Default Timezone on each Store record so it is calculated in the right zone.
• Reconciling against a payment provider’s payouts: use Paid At on the Payment records, converted to the timezone the provider uses to cut its payout batches. Providers group payouts by their own business day, which does not always match the store’s day, so match on the payment timestamp rather than Order Start Date.
• Matching a customer’s account of when they ordered: Submitted Date, converted to the customer’s timezone.

After reading an order this way you can name each figure on it: what was charged, what was collected, and on which business day.