Introduction

The Reconify API helps you monitor money movement across the services that carry it. Your payment, wallet, ledger, and fulfillment systems send events, and Reconify tells you when a workflow does not finish the way it should.

​

What is Reconify

Reconify is payment monitoring infrastructure for distributed financial systems. As money moves across your services, payment providers, wallets, ledgers, and other financial systems, Reconify reconstructs each financial operation from the events those systems produce and verifies that the expected outcome actually happened. When a payment flow breaks, Reconify does more than tell you that something went wrong. It preserves the operation timeline, financial context, provider and internal references, amounts, timestamps, expected stages, and the evidence your team needs to investigate what happened.

​

What Reconify does

A financial operation rarely happens in one system. A payment can begin in your application, succeed at a payment provider, trigger an internal service, credit a wallet, update a ledger, and eventually settle somewhere else. Each system sees only part of that operation. Reconify connects those parts. Your systems send financial events to POST /v2/events. Reconify stores the accepted events as immutable evidence, connects related evidence into financial operations, and evaluates those operations against the flow and deadlines you define. This gives Reconify three jobs:

1. Reconstruct the operation. Connect evidence from distributed systems into one financial timeline.
2. Verify the expected outcome. Determine whether the financial operation completed the way the flow says it should.
3. Preserve the investigation context. When reality diverges from the expected outcome, keep the affected operation and its evidence together for investigation.

The result is continuous payment monitoring without putting Reconify in the critical path that moves money.

​

How it works

Evidence travels one way, from your services to a finding: The pipeline runs in five steps:

1. Your systems send events with a flow, event type, operation reference, entity ID, and the time the event occurred.
2. Reconify stores every accepted event as immutable evidence.
3. Events that share a reference assemble into one operation. Delivery order does not decide business order, because Reconify sorts by event time and breaks ties with the event ID.
4. The evaluator compares the operation against the flow’s expected stages and deadlines.
5. An operation that misses its expectations produces an evidence-backed finding you investigate in the dashboard.

​

Send events Reconify can work with

Evaluation is only as good as the evidence behind it. Four fields decide how much Reconify can do with what you send:

• event.id from your source system identifies an exact replay, so a retry returns duplicate instead of storing the same event twice. An event without an ID receives a generated one and is unsafe to retry.
• occurred_at from the source system carries the business time. Deadlines run on that time, not on the moment the request reaches the API.
• reference stays identical across every event in one operation, because it is the value that assembles the operation.
• correlation_id links evidence across services when one business transaction produces several operations under different references.
• causation_id identifies the single earlier event that led to an event.

The richer each event is, the more precisely Reconify links it. The API reference has the exact fields, scopes, and responses.

​

Start here

Four pages cover the path from a key to a monitored flow.