Phase 3 · Transactions and fulfillment
Payments and Payouts: Eligibility, Account Verification, and Settlement Acceptance
Confirm country and business eligibility, activate appropriate methods, connect payout, run complete test-mode payments, and verify refund, fee, dispute, and reconciliation boundaries.
What counts as complete in this lesson
Use Settings > Payments to reach the correct page, then configure, save, verify, and record the result. Completion means you can point to the saved state, verification result, and condition for continuing.
- Admin path
- Settings > Payments
- Lesson output
- A payment evidence package covering eligibility, activation, verification, payout, methods, test order, refunds, fees, disputes, and reconciliation.
- Continue when
- Payment methods are eligible in the target market, payout is explainable, test payment/refund pass, and fees/disputes/reconciliation have owners.
- Stop when
- Pause launch when eligibility is unknown, verification is paused, payout is unconnected, testing may charge real money, or refunds/disputes have no owner.
Evidence boundary: A visible button, Payment active state, or test success does not prove live payout, refunds, fees, disputes, or every market; these are separate states.
Why this lesson comes now
Payments combine eligibility, entity verification, market, currency, payout, refunds, and disputes. Seeing a checkout button does not prove legal collection, timely payout, customer refunds, or finance reconciliation.
Prepare before opening the admin
- Confirm launch country, entity, product category, and payment eligibility.
- Prepare redacted business details and payout owner.
- Confirm test mode and do not use real customer cards or live payment details.
Follow the English admin step by step
After each step, refresh the admin or verify the storefront. A saved admin state does not automatically prove the customer-facing result.
Confirm country and business eligibility first
In Payments, confirm target country, entity, business type, product category, and verification materials. When eligibility is unclear, prepare questions and documents instead of submitting unnecessary sensitive data.
Expected result: Have payment availability, eligibility conditions, document owner, and blockers.
Completion standard: Payment methods, entity, and product category for the launch market are explainable; unmet methods stay inactive.
If the result is missing or wrong: When eligibility differs from expectation, confirm country, store entity, market, and product category instead of changing details to bypass review.
Evidence to keep: Record country, method, eligibility state, document list, and owner without storing sensitive payment details.
Activate Shopify Payments and submit details
Submit required details for the store entity and market while separating activation, verification, payout, and reserve states. Submit only after confirming purpose and access; do not treat a test store as a production payout account.
Expected result: Have activation state, verification state, restrictions, and next actions.
Completion standard: Payment availability in the target market matches entity, product, and risk conditions.
If the result is missing or wrong: When verification pauses or requests more documents, keep state and owner, then supply the checklist without submitting contradictory details.
Evidence to keep: Record redacted state, restriction, submission time, and next review without capturing identity or bank documents.
Failure handling: When payment is not active, keep launch blocked; a visible button or test mode is not live payment approval.
Connect the payout bank account
Verify payout bank account, settlement currency, payout schedule, and owner. Keep redacted evidence and never expose real account details in public pages or code.
Expected result: Have payout account, currency, schedule, state, and reconciliation owner.
Completion standard: Payout state, order collection, balance, and reconciliation convention can be read back by one owner.
If the result is missing or wrong: When payout verification fails, confirm entity, currency, bank requirements, and input response without printing real account numbers.
Evidence to keep: Record redacted account identifier, currency, schedule, verification result, and time.
Configure PayPal and other methods
Enable only methods supported in the target market and manageable for refunds and disputes. Check account connection, currency, checkout display, fees, and support ownership instead of enabling every selectable icon.
Expected result: Have alignment between payment method, account connection, fees, refund, and dispute ownership.
Completion standard: Customers see appropriate methods in the target market and the team knows how to refund, reconcile, and handle disputes for each.
If the result is missing or wrong: When a method is missing in checkout, check market, currency, account connection, product, and eligibility instead of only refreshing.
Evidence to keep: Record method, market, currency, fee summary, test result, and owner.
Run a complete payment in test mode
In test mode, run from product and cart through checkout and payment confirmation, checking amount, discount, tax, shipping, order state, and notifications. Confirm no unintended real charge occurs.
Expected result: Have actual records for payment success/failure, order creation, and notifications.
Completion standard: At least one success and one failure/cancel path are explainable without polluting live reconciliation.
If the result is missing or wrong: When payment fails, confirm test mode, store, market, and test method before separating account eligibility from checkout configuration.
Evidence to keep: Keep test order, payment result, state, notification, and time without storing full card details.
Verify refunds, fees, disputes, and reconciliation
Use test orders to review refund, cancellation, fee, and dispute records, and map amount, timing, state, and notification into reconciliation. Payment success does not prove payout and refund readiness.
Expected result: Have a state map for payment, payout, refund, fees, and disputes.
Completion standard: Finance can reconcile orders, transactions, fees, and payouts, and customer refunds have an actual result.
If the result is missing or wrong: When amounts or states disagree, keep redacted transaction references and compare payment platform, Shopify order, and bank payout separately instead of overwriting differences with a total.
Evidence to keep: Record redacted order/transaction references, refund state, fees, payout, and reviewer.
Failure handling: When payment succeeds but payout, refund, or dispute handling is unclear, mark only partial progress and complete the finance responsibility chain first.
Apply the decision in your store
Confirm launch country and entity eligibility, then use test mode for product, checkout, success, failure, refund, and cancellation paths. Keep redacted payout state; only methods the team can refund, reconcile, and dispute belong on the launch list.
Use the admin path above, then apply it to one concrete situation.
Use this lesson in your store
By the end, you should have: A payment acceptance sheet with status, entity, settlement currency, payout account, fee source, test result, refund path, dispute owner, and reconciliation evidence for every method.
Relevant admin path: Settings > Payments
Make the decision before reading the reason
Choose the action that solves the problem first, then read the explanation.
Confirm these items in your store
Check each item against the current store; this checklist does not save settings or run tests.
This screen still cannot tell you: A payment button or Active status does not prove final approval, received payouts, controlled dispute risk, or availability in every market
Continue when: entity and account match, success and failure paths pass, refunds are traceable, and a second person confirms test mode is off
Stop when: If review is pending, the account is not entity-controlled, test mode is not confirmed off, or money cannot be reconciled, stop launch work
Next: Next, configure Checkout and Customer accounts around real fulfillment data, consent, and sign-in paths.
Complete the decision or checks first. When information is missing, a pause is safer than guessing a pass.
Decisions to make in this lesson
Enter the actual values for this store row by row. Do not treat examples or planned values as completed work. Mark a row passed only when the condition and saved or tested evidence are present.
| Item | Recommended setting | Why |
|---|---|---|
| Primary payment method | Eligible and market-supported | Avoids checkout payment failure |
| Payout account | Entity and currency match | Supports payout and reconciliation |
| Test mode | Run success/failure/refund first | Avoids unintended live charges |
| Disputes and refunds | Owned and recorded | Makes customer/finance results traceable |
Do not change these blindly
- Do not treat Payment active as payout, refund, and dispute completion.
- Do not run a payment before confirming test mode.
- Do not expose real bank, identity, or transaction information.
FAQ
Does Payment active mean payouts work?
Not necessarily. Activation, verification, payout bank account, schedule, and restrictions are separate states.
Can we accept live money after test mode passes?
Confirm eligibility, entity, market, account verification, payout, and refund/dispute flow; test mode is path evidence only.
Why not enable every payment method?
Each method has account, currency, fee, refund, dispute, and support responsibilities; enable only methods the team can operate.
Conclusion and continue line
Payment acceptance separates “can click Pay” into eligibility, activation, verification, payout, test payment, refund, fees, disputes, and reconciliation. Continue only with redacted evidence and owners for each chain; keep unverified methods off.