Accept, pay out, reconcile. Built for the day the rail fails halfway.

Stripe, Checkout.com, Unit, Plaid, Adyen. Visa Direct and Mastercard MoneySend push-to-card. Every integration we build carries idempotency, duplicate-event protection, partial-failure recovery and a reconciliation your finance team can close the month from.

Take the Payments Readiness Scorecard

Payment Operations Assessment $9,500 one week, single rail $14,500 two weeks, multi-rail or payouts

Start here: the free Payments Readiness Scorecard

Fifteen questions from our acceptance checklist, two minutes, scored in your browser. It tells you whether money can be duplicated or lost silently today and what to fix first.

Fixed-fee assessment

Payment Operations Assessment, one week, single rail$9,500
Payment Operations Assessment, two weeks, multi-rail or payouts$14,500

Payments Readiness Scorecard Example result

36 / 100 At risk

Illustrative example, not a client's data.

Idempotency1.5/6

Webhooks and events2/5

Partial failure1.5/5

Ledger3/3

Reconciliation0/5

Payouts1/2

State machines1/1

Card data2/2

Observability0/2

Testing0/2

Do these first

Idempotency. Persist a request row keyed by business ID before the call; make the ledger write conditional on it.
Webhooks and events. Event-ID table with a unique constraint; match on provider object ID, never on amount.
Reconciliation. Daily job comparing ledger, provider balance and bank statement; tolerance zero on count, one minor unit on amount.

Fifteen questions, two minutes, scored in your browser

Payment Operations Assessment

One or two weeks, fixed fee. We map every flow that creates, moves or refunds money; test the failure modes; review reconciliation across ledger, provider and bank; and hand you a severity-ranked findings report, a target design, a costed roadmap and a fixed-price quote for the build. $9,500 for one week, single rail; $14,500 for two weeks, multi-rail or payouts. Half on signature, half on delivery.

Book the Payment Operations Assessment

Integration and Reconciliation Build

Fixed price, with a date and a change-control clause. Milestone billing. Delivered against our 42-item acceptance checklist, which you can read below.

Money-Code Assurance

Test automation and a safety net for money-handling code: idempotency suites, ledger reconciliation under load, decimal precision, KYC state machines, compliance traceability. Sold after a build, or before an audit or a launch.

Reconciliation and Payouts Retainer

Priced on response time and coverage, on what we built.

Our payments acceptance checklist

The checklist every money-handling change is delivered against. Used inside the Payment Operations Assessment (report §7), inside every Integration and Reconciliation Build, and published as Aripone's playbook. Codified from patterns delivered on a regulated fintech platform (Unit, Checkout.com, Plaid, Visa Direct, Mastercard MoneySend). Version 0.1, 2026-09-09.

Each item: pass / fail / n.a., with evidence.

1. Idempotency

1.1Every write that creates, moves or refunds money carries an idempotency key derived from a business identifier, not a random value generated per attempt.
1.2A request record is persisted before the provider call, so a retry after a crash finds the prior attempt.
1.3The provider is sent the same key on retry, and the code handles "already processed" as success.
1.4Retries are bounded, backed off, and never change the amount or the recipient.

2. Webhooks and events

2.1Signatures are verified before any processing.
2.2Event IDs are stored with a unique constraint; a duplicate is acknowledged and ignored.
2.3Events are applied in the same transaction as the ledger write.
2.4Matching is by provider object ID, never by amount or timestamp.
2.5Out-of-order events are handled (a paid before a created does not corrupt state).
2.6A replay of any event from the last 30 days is safe, and has been tested.

3. Partial failure

3.1The sequence "provider accepted, our write failed" is handled: a reconciler or the request record closes the gap.
3.2The sequence "our write succeeded, provider rejected" is handled: the ledger row is voided by a new entry, not deleted.
3.3Timeouts after the provider accepted are treated as unknown, not as failure; the state is resolved by query before any retry.
3.4A worker restart mid-job cannot duplicate money (tested by killing the worker in a sandbox run).

4. Ledger

4.1Money is stored as integer minor units or a fixed-precision decimal; never floating point.
4.2Currency is stored with every amount.
4.3Ledger rows are immutable; corrections are new entries with a reference to the original.
4.4Every balance can be recomputed from entries and matches the stored balance.
4.5Rounding rules are explicit and applied in one place.

5. Reconciliation

5.1A three-way tie-out exists: internal ledger, provider balance, bank.
5.2It runs at least daily, automatically, with a tolerance of zero on count and one minor unit on amount.
5.3Breaks land in a queue with an owner and an age; nothing is "carried forward" silently.
5.4Month-end closes from system data without a spreadsheet.
5.5Provider fees, FX and reserves are modeled, not netted away.

6. Payouts and disbursement

6.1A payout is created only against settled, available funds.
6.2Recipient identity is verified at onboarding and immutable at payout time.
6.3Manual payouts above a threshold need two people.
6.4Cut-offs and schedules are configuration, not code.
6.5Failed and reversed payouts are handled as first-class states with a ledger effect.

7. State machines

7.1Refund, dispute, subscription and KYC states are defined in one place with allowed transitions.
7.2A state cannot be skipped or set arbitrarily by an admin action.
7.3Historical re-evaluation (re-running rules over past events) produces the same result, and there is a preview-before-activate step for rule changes.

8. Card data and scope

8.1No raw PAN is stored, logged or passed through application servers (hosted fields or tokenization).
8.2The PCI SAQ level is known and documented.
8.3Logs and error reports redact card and bank data.

9. Observability

9.1Alerts exist for: money accepted by a provider with no ledger row; unreconciled amount above threshold; payout batch stuck; webhook backlog.
9.2Each alert has a runbook and a named on-call owner.
9.3Every money write is traceable end to end by one correlation ID.

10. Testing

10.1End-to-end tests cover every money flow against the provider sandbox, in CI.
10.2Forced-failure tests exist: timeout after accept, webhook replay, worker restart mid-job, provider 5xx.
10.3Precision tests cover rounding, currency and large amounts.
10.4A change to a money path cannot merge without the suite passing.

42 items. Aripone LLC, https://aripone.com/. Feedback to hello@aripone.com.