Payment Infrastructure for Prop Firms: Challenge Purchases, Refunds & Payout Flows

Challenge purchase versus broker deposit: why the difference matters

A retail brokerage deposit funds a trading account with the client's own money, which the broker then has obligations to segregate, report and potentially return on withdrawal. A prop firm challenge purchase is different in kind: the trader pays a fixed fee for a product — access to an evaluation, with defined rules, for a defined period. No client money is being held for trading; the firm is selling participation in a programme it administers. This is closer to a subscription or software licence sale than a deposit.

That distinction is not cosmetic. It affects how a payment provider classifies the merchant account, what documentation and risk disclosures the provider expects, how a "refund" is even defined (money back for an unused or cancelled product, not a client-money withdrawal), and how the firm should think about dispute evidence — the evidence you need is proof of product delivery (the evaluation was provisioned and accessible) and program terms accepted at checkout, not evidence of trade execution or fund custody. Card networks' own dispute frameworks are built around merchant-of-record product and service sales, and firms benefit from mapping their purchase flow explicitly onto that framework rather than assuming it behaves like a brokerage deposit. See Visa's and Mastercard's published dispute guidance for how "services not rendered" and cancellation conditions are actually defined and evidenced [2](https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/merchants-dispute-management-guidelines.pdf) [3](https://www.mastercard.com/content/dam/public/mastercardcom/na/global-site/documents/chargeback-guide.pdf).

None of this is a classification the firm can settle by itself. Whether a challenge purchase is treated as a digital good, a service, or something else by a given payment provider, acquirer or card scheme depends on that provider's own risk appetite, the jurisdiction the firm operates from, and the firm's own legal and compliance advice. What a firm can control is presenting the transaction consistently and accurately — clear product description at checkout, clear terms, and a payment flow that does not resemble deposit-taking — so that provider due diligence has an accurate picture to assess.

   CHECKOUT (inbound)                         PAYOUT (outbound)
   ------------------                         -----------------
   Trader selects challenge
        |
        v
   Checkout: price, currency,          Payout request approved
   payment method, fraud screen        in CRM back office
        |                                     |
        v                                     v
   Payment provider authorises         Payout provider / banking
   and captures                        rail disburses to trader
        |                                     |
        v                                     v
   Order record created in CRM         Payout record created in CRM
        |                                     |
        v                                     v
   Provider settles funds to firm      Funds debited from firm's
        |                                     operating/payout balance
        v                                     
   Reconciliation: checkout log
   <-> CRM order <-> settlement file
        |
        v
   Refund / chargeback path
   (separate from payout path,
   separate provider relationship)

Checkout and payment method mix

Challenge checkout typically needs to support cards as the dominant method, plus regional alternatives (local bank transfer rails, open-banking payments, e-wallets) and, for some firms, crypto. Each method has a different settlement time, a different refund mechanism, and a different fraud profile. A card refund reverses to the original card; a crypto payment generally cannot be "refunded" in the card sense at all — it requires an outbound transfer, which raises its own AML and address-verification questions the firm's compliance advisor should weigh in on before crypto is offered as a checkout option.

Operationally, checkout should record, against a single order ID: amount, currency, method, provider transaction reference, IP and device fingerprint at time of purchase, and the product/programme SKU purchased. This record is what everything downstream — refunds, disputes, reconciliation — is built on.

Currency handling

Firms selling globally price challenges in one or more settlement currencies while accepting payment in others. Decide, deliberately, whether the trader is charged in the firm's base currency (provider or card network handles conversion) or in local currency (the firm absorbs or passes through FX risk). Whichever model is chosen, the CRM order record needs both the charged amount/currency and the settled amount/currency, because refund amounts and reconciliation both depend on knowing which one applies. Mixing this up silently is one of the more common sources of reconciliation drift once volume grows across regions.

Failed and duplicate payments

Retry logic on checkout (card declines, timeouts, 3-D Secure abandonment) can generate duplicate authorisations if not handled carefully. The order record should be created on successful capture only, with a distinct status for abandoned or failed attempts, so support staff are not chasing "did I get charged twice" tickets without a clear system answer. A duplicate capture, if it happens, should be refunded promptly and logged as an operational incident, not quietly written off — providers and card schemes both track refund and error rates as a signal of merchant health.

Refunds and partial refunds

A refund on a challenge purchase is a decision the firm makes under its own published terms (for example, a short cooling-off window before the evaluation is provisioned, or no refund once trading access has been granted — whatever the firm has actually committed to in writing). The back office needs a defined refund workflow: who can authorise it, whether it is full or partial, and a reason code recorded against the order. That reason code matters later — it is the difference between a clean internal refund log and having to reconstruct, case by case, why money went back when a provider asks for refund-rate context.

Partial refunds (for example, where a bundled add-on is refunded but the base challenge fee is not) need explicit handling in the order model; treating every refund as "the full order, reversed" breaks reconciliation the first time a partial case appears.

Chargebacks and dispute evidence

A chargeback is initiated by the cardholder's bank, not the firm, and runs on the card scheme's own timeline and evidence rules — the firm is responding to a claim, not deciding whether one is opened. What the firm can control is the quality of the evidence it can produce quickly: proof the product (challenge access) was delivered, the terms the trader accepted at checkout, purchase IP/device data, and — where relevant — evidence of platform access or activity showing the evaluation was actually usable. Visa and Mastercard both publish current dispute condition definitions and merchant evidence expectations, and the specific reason code raised determines what evidence is actually relevant [2](https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/merchants-dispute-management-guidelines.pdf) [3](https://www.mastercard.com/content/dam/public/mastercardcom/na/global-site/documents/chargeback-guide.pdf).

This is a strong argument for keeping the CRM order record and the checkout/provider records tightly linked from day one: assembling dispute evidence under a scheme deadline is not the moment to discover that the order record and the payment reference were never reliably joined.

Fraud screening

Challenge products are attractive to fraud rings for a specific reason: a successful, undetected fraudulent purchase can be followed by a payout claim if the account passes evaluation before the fraud is caught, turning a payment fraud problem into a payout-risk problem. Screening at checkout — velocity checks on card/IP/device, mismatched billing geography, known high-risk BIN ranges — should feed the same review flags that risk and operations use downstream, rather than living only inside the payment provider's own dashboard disconnected from the CRM. See our coverage of prop firm payments & payouts for how payout risk checks connect to purchase-side signals.

Reconciliation across three records

At any point, three independent records should agree: the checkout/gateway log, the CRM order record, and the provider's settlement file (what actually landed, net of any provider fees, in the firm's account). Discrepancies between them — a captured payment with no CRM order, a settled amount that does not match the charged amount, a refund issued in the CRM but not reflected in the provider's ledger — are where financial and audit exposure actually accumulates. Daily or near-daily automated reconciliation between these three sources, surfaced in the prop firm CRM back office rather than in a spreadsheet someone builds manually at month-end, is what keeps this manageable as purchase volume grows.

Separating inbound purchase rails from outbound payout rails

Purchase money coming in and payout money going out should be treated as separate flows, often through separate provider relationships, for reasons beyond bookkeeping tidiness. Providers assess risk differently for consumer-collections flows versus recurring disbursement flows; a single blended relationship can create confusion about what the provider is actually underwriting. Separation also gives the firm cleaner internal controls — the team approving payouts is not the same flow as the team handling purchase refunds — and cleaner reconciliation, since inbound and outbound ledgers do not need to be untangled from a single mixed account. Our dedicated coverage of payout mechanics, review and payment operations lives in prop firm payments & payouts; this article is scoped to the inbound side and the handoff between them.

Onboarding a payment provider: what to expect generally

Payment providers underwrite the merchant, not just the transaction. Expect requests for: corporate registration and beneficial ownership documents, a description of the product being sold (framed accurately as evaluation/challenge access, not as a brokerage or investment product, unless it genuinely is one), sample terms and refund policy, projected transaction volumes and average ticket size, website and checkout flow review, and AML/KYC policy documentation for the firm itself. Providers may also ask how the firm handles payout of any funded-account amounts, since that downstream process can factor into how they assess overall risk even though it runs on a separate rail. None of this is standardised across providers — acceptance, required documentation, and the specific classification applied are decided by each provider under its own risk policy, and firms should treat this as a commercial and legal conversation to run with counsel and with the provider directly, not as a checklist that guarantees an outcome.

Operator checklist: inbound payment stack

• Checkout records amount, currency, method, provider reference and product SKU against one order ID.
• Charged and settled currency/amount both stored, not assumed equal.
• Refund policy published in writing and mirrored in a CRM-enforced workflow with reason codes.
• Fraud screening signals (velocity, device, BIN, geography) feed the same system operations and risk use.
• Dispute evidence (delivery proof, accepted terms, purchase metadata) retrievable without manual reconstruction.
• Daily reconciliation across checkout log, CRM order and provider settlement file.
• Inbound purchase rail and outbound payout rail run through separate provider relationships and separate approval flows.

Operator checklist: provider onboarding readiness

• Corporate documents and beneficial ownership records current and complete.
• Product description accurately reflects an evaluation/challenge offering, reviewed by counsel.
• Terms of service and refund policy published and consistent with what checkout actually enforces.
• Realistic volume and average-ticket projections, not aspirational figures.
• AML/KYC policy documentation for the firm's own onboarding, available on request.
• Legal advice taken on classification and jurisdictional exposure before representing anything to a provider.

Frequently Asked Questions

Is a challenge purchase the same as a brokerage deposit for payment purposes?

No. It is a product purchase for evaluation access, not client money held on account. The two should be modelled, disclosed and reconciled differently, and providers frequently assess them under different risk frameworks.

Can Infy Trade Tech guarantee a payment provider will accept a prop firm?

No. Provider acceptance, account classification and terms are decided by each provider under its own policy and depend on jurisdiction, documentation and the provider's risk appetite. We build the checkout, CRM order and reconciliation infrastructure; the underwriting decision is the provider's, taken alongside the firm's own legal and compliance advice.

Should refunds and payouts use the same payment provider?

Not necessarily, and often not ideally. Keeping inbound purchase/refund flows and outbound payout flows on separate rails simplifies reconciliation and gives providers a cleaner risk picture of each flow.

What evidence actually helps in a chargeback dispute?

Proof the evaluation product was delivered and accessible, the terms the trader accepted at checkout, and purchase metadata (IP, device, timestamp) tied to the order record. The specific evidence that matters depends on the dispute reason code raised by the card scheme.

Does accepting crypto for challenge purchases avoid chargeback risk?

It removes card-network chargebacks for that payment method, but it introduces its own AML, reversibility and compliance considerations that should be reviewed with legal counsel before being offered at checkout.

Related Prop Firm Research

• Prop Firm Back Office: What Operations Teams Need Beyond the Trader Dashboard
• Prop Firm Payout Infrastructure: Requests, Review, Risk Checks & Payment Operations
• Prop Firm CRM Architecture: From Challenge Purchase to Funded Account
• Prop Firm Technology Stack: CRM, Trading Platform, Risk, Payments & Operations
• All prop firm research