THE PROBLEM
When a payment is taken outside XTruLink, Altru records the BBMS authorization code in its Authorization Code field, and that code matches the BBMS transaction report exactly. Reconciling the two systems is a simple deterministic join.
When a payment is taken through XTruLink, Altru records the XTruLink Order ID in that same field instead. BBMS still records its own authorization code. The two systems no longer share any common unique identifier, so the join is impossible.
Example from our data: one order appears in BBMS with authorization code 04743I, and the same order appears in Altru with 592, which is the XTruLink order ID. Same transaction, same amount, same card, no shared key.
We have searched both Altru and BBMS and cannot find any single field that reliably links the two.
IMPACT
Our BBMS reconciliation was fully automated before we moved ticketing to XTruLink. We now run a fuzzy match built on card last four, amount, and transaction date. Across 523 orders in one recent week, 5 came back ambiguous and needed manual review. That is workable but it is not deterministic, and the ambiguity rate will scale with volume.
We expect this affects any XTruLink client running Altru with BBMS who reconciles payments, which we would guess is most of them.
PREFERRED SOLUTION
Write the BBMS authorization code into Altru alongside the XTruLink order ID, rather than in place of it. Either populating the Authorization Code field with the BBMS code and carrying the order ID elsewhere, or adding the BBMS code to an additional field, would restore a deterministic join and require no new reporting on anyone's part.
ALTERNATIVE SOLUTION
If the above is not feasible, a report in XTruLink that maps the two identifiers to each other would solve it. Fields we would need:
XTruLink Order ID
BBMS Authorization Code
Altru payment reference (the Payment-Order-NNNNNNNN value)
Transaction date and time
Account holder name
Card type and last four
Gross amount, fee amount, net amount
Both the XTruLink fee and the BBMS fee, shown separately
Transaction result (approved, declined, refunded, voided)
Disbursement date
Two structural notes on that report. It needs to include refunds and voids, not only sales, since those have to reconcile too. And it should be row-per-transaction rather than row-per-order, so split payments and partial refunds each appear on their own line.
AUTOMATION
This is the part that matters most to us. A report our accountants download by hand replaces one manual process with another.
In order of preference:
An API endpoint we can query on a schedule, returning JSON or CSV for a given date range.
A scheduled push to an S3 bucket or SFTP destination we provide, running daily.
A scheduled email delivery of the report as a CSV attachment.
Any of the three would let us restore the automated pipeline. The first would be the most robust for us, since we already run our reconciliation in AWS Lambda.
