A payment reference can contain digits without being a number

A reference identifies a record. It does not necessarily represent a quantity that software should add, round or compare numerically. Converting a long digit string into a numeric type can destroy the distinction between two records while leaving a plausible-looking value on screen.

This fictional example follows a merchant's reconciliation adapter. No payment is made. The provider contract, transactions and account are invented to make the data boundary explicit; they are not a claim about a particular provider's availability in Israel.

Establish what the provider actually supplies

The inspected fixture contract returns transaction_reference as a JSON string. The merchant must preserve that string exactly when requesting the corresponding transaction. Amount, currency and payment state are separate fields.

Two synthetic records are relevant:

Both responses belong to the same authorised test account. Their different amounts help the investigation distinguish the records, but amounts are not used as substitute identifiers. O-41 is already reconciled. O-42 remains in the staff review queue after its lookup fails to establish the expected transaction.

Find the first change in the reference

The raw response for O-42 contains the exact string ending in 993. The adapter calls JavaScript's Number() on that field before storing it. The resulting value ends in 992, the same numeric value produced from O-41's reference.

The problem is not a Hebrew or Arabic display direction, a currency separator or a provider delay. The source response is intact. The first destructive operation is the unnecessary numeric conversion.

JavaScript's maximum safe integer documentation explains the safe integer range of its Number type. In a direct runtime check, these two strings convert to equal Number values even though their original characters differ. Converting that rounded value back into a string cannot recover the lost digit.

The adapter's existing amount and order checks prevent it from marking O-42 reconciled with O-41's transaction. That safeguard contains the error; it does not make the reference conversion acceptable.

Keep identity separate from arithmetic

The selected repair removes numeric conversion from this opaque field. The supported storage, request builder and comparison path now retain the exact string. Validation follows the provider fixture's documented identifier contract and rejects missing or malformed values without inventing a replacement.

Changing the field to a larger numeric type would still impose arithmetic meaning that this contract does not require. The chosen representation is text because the provider defines a text identifier. Other systems may specify different types; the decision should follow the inspected interface rather than the appearance of a value.

Amount calculations remain in their own fields under the merchant's approved money rules. The repair does not alter ILS 240.00 or ILS 315.00, currency handling, tax treatment or capture state.

Resolve the pending record from authoritative evidence

Correcting future responses does not repair O-42's already rounded stored reference. The fictional operator uses the retained authorised source response and the provider's supported read-only lookup to recover the exact reference. They verify its account, merchant order, currency, amount and current state before approving the reconciliation update.

O-42 is then linked to the transaction ending in 993 and leaves the unresolved queue as reconciled. The audit records the old corrupted value, the exact recovered value and the evidence supporting the correction. No new charge, capture or refund request is sent.

If the original response had been unavailable, guessing the final digit would not have been an acceptable recovery. The record would have remained unresolved while the operator obtained authoritative evidence through the provider's supported process.

Check both records and the failure paths

The final fixture reads O-41 and O-42 separately. Each request carries its exact string, each response matches the expected merchant record, and the two stored associations remain distinct. O-41's earlier reconciliation and amount are unchanged.

An unknown reference returns the fixture's documented not-found response and creates no association. A missing reference is held before lookup. A response with the right reference but an unexpected order or currency fails reconciliation rather than borrowing the expected values from the local order.

The operator also reviews the retained raw response against the newly saved field. This prevents a superficial repair in which only the display has been changed while the internal lookup key remains rounded.

Decide the scope of the wider review

The demonstrated pair proves the defect and its bounded correction. It does not identify every affected historical transaction. The real assessment would need a defined period, retained evidence, access permissions and an approved reconciliation procedure. Any financial adjustment belongs to a separately authorised decision.

For a new integration, include identifiers beyond ordinary small examples in the test data. Follow them through response parsing, persistence, staff search, exports and subsequent requests. A successful request with reference 12345 would not expose this failure.

The integration service can examine these boundaries with the merchant's actual provider contract. The online commerce service connects that technical work to the order and staff workflow, while the merchant and relevant advisers retain responsibility for commercial and regulatory decisions.