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 | Payments tied to the same invoices in the books |
| Invoices | Match the invoices in QuickBooks |
| Subscriptions | MRR that matches recognised revenue |
| Products | The same items as the accounting catalog |
More via the execute API.
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, the cash lands in the Plaid bank feed, and the timing is consistent. You can finally test payment reconciliation end to end.
Native-shaped, with planted edge cases
Point your Stripe client at the Fictix base URL and send your Fictix project key (X-API-Key) instead of a Stripe secret key. Responses follow Stripe's shape, so most client code works with little or no change. Then plant the nasty ones — a duplicate charge, a payment that doesn't match its invoice, revenue 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 customers, charges, invoices and subscriptions reconcile with that company's accounting and bank records.
Can I keep my Stripe SDK?
Mostly. Point it at the Fictix base URL and send your Fictix project key (X-API-Key); responses follow Stripe's shape, so most client code works with little or no change. Webhooks are Fictix's own: they're signed with X-Fictix-Signature (HMAC-SHA256), not Stripe-Signature, so verify them with your Fictix webhook secret.