Synthetic Stripe test data that ties to the books.
Stripe test mode gives you isolated objects. Fictix gives you Stripe-shaped data that reconciles with the same company's accounting and bank records.
What you get
| Object | Notes |
|---|---|
| Customers | Map to the same accounting customers |
| Charges / PaymentIntents | Succeeded, failed, refunded mix |
| Invoices / Subscriptions | MRR that matches recognised revenue |
| Payouts | Net of fees, landing in the bank feed |
| Balance transactions | Fee-level detail for reconciliation |
| Disputes / Refunds | For edge-case and fraud testing |
Why 'ties to the books' is the point
In Stripe test mode, a charge means nothing elsewhere. In Fictix, a charge's revenue shows up in QuickBooks, its payout (net of fees) lands in the Plaid bank feed, and the timing is consistent. You can finally test payout reconciliation and fee accounting end to end.
Native-shaped, with planted edge cases
Your existing Stripe client points at the Fictix base URL and works unchanged. Then plant the nasty ones — a duplicate charge, a payout that doesn't net out, a refund booked to the wrong period — and score your detection.
Questions
How is this different from Stripe test mode?
Stripe test mode is isolated. Fictix's Stripe-shaped data belongs to a whole company, so charges, payouts and fees reconcile with that company's accounting and bank records.
Can I keep my Stripe SDK?
Yes — the surface is Stripe-shaped, so your client and webhook handling work against the Fictix endpoint unchanged.