SourceOrderTransactionId inconsistency

GraphQL Admin API Troubleshooting
1

I am trying to match BalanceTransactions to OrderTransactions.

Looking at balanceTransactions I see the following field.

With the following description.

The id of the Order Transaction that resulted in this balance transaction.

Seems to be exactly what I am looking for. A direct foreign key from BalanceTransaction to OrderTransaction. I can now use this Id to find the OrderTransaction

WRONG!

SOMETIMES, it is the direct foreign key, but OTHER TIMES, it is the ID of the PARENT transaction.

OK, not too bad, we can check for both values. Sometimes it actually matches the grandparent (the parent of the parent) of the transaction. That’s OK as well, recursion exists for a reason.

Hmm, wait a minute, won’t that introduce false positives? Yes it will, however usually only refunds have grandparents, so we can check if the type of the balanceTransaction matches the type of the OrderTransaction (with some mapping involved).

OK, this is manageable.

Now I have found an edge case. the ID matches a SIBLING Transaction (both share the same parent)

Now what? I can check sibling transactions, but this will most probably result in false positives.

And I go back to the wording of the documentation.

The id of the Order Transaction that resulted in this balance transaction.

I can see how the order transaction itself resulted in the balance transaction. I can see how the parent transaction (indirectly) resulted in the balance transaction. I can see how the auth of the order that was refunded resulted in the refund balance transaction, but I fail to see how a sibling transaction “resulted” in this transaction.

What should have been a simple task, (matching one id to the other) has morphed into a complicated mess.

My biggest issue is that it isn’t consistent, if it would always match the sibling ID then OK, I can write nonsensical code. But as it stands, this would find false positives.

NOTE: I am using the Rest version to get balanceTransactions, because the GraphQL version requires different scopes, (which should be fixed, either with a top level query for balanceTransactions or smarter checking on the shopifyPaymentsAccount query for scopes. but this is not the topic now)

PS: I have tried using both amounts and processing dates to match. They don’t work. They have edge cases as well, and those are much harder to navigate without causing false positives.

2

Update: I have requested the new scope in order to check the GraphQL version. It has the same values, so this is not a REST specific issue.

3

Okay, this is insanity.

I have now found an order transaction with 3 siblings. Two balance Transactions share one id (a sibling) while the third one has its own. Searching for siblings, causes a false positive. Not searching for siblings, causes a false Negative IN THE SAME ORDER. For the SAME Auth transaction.

Please, I need some clarity on this.

4

Hi @SRCB - I had a quick look and the inconsistency you’re describing with sourceOrderTransactionId pointing to different levels of the transaction hierarchy is not explained anywhere in the documentation.

There have been related issues in this area before where balance transaction linking fields weren’t populated correctly for certain transaction types. Those were tracked and fixed incrementally by the Payments team, but what you’re seeing here is a different problem since the field is populated, just inconsistently.

I’d like to confirm the expected behavior with the relevant team, but I’ll need some concrete examples to give them something actionable.

Can you share the myshopify.com URL along with a few specific order and transaction IDs that demonstrate each pattern? Ideally one where sourceOrderTransactionId matches the direct transaction, one where it matches a parent or grandparent, and one showing the sibling case. If you’d rather send these details via DM then let me know.

I’ll take a closer look and raise the inconsistency with the relevant team if need be - thanks!

5

@Donal-Shopify I am trying to create a PM, but I don’t see that option.

6

I just sent a DM, thanks for your patience!

8

Thanks for the detailed examples via DM, @SRCB.

I can confirm this is an issue being tracked internally with how balance transactions are linked to order transactions in multi-capture scenarios. I’ve shared your examples with the relevant team and I’m currently waiting to hear back from them.

As a partial workaround, you can query order transactions directly via the Orders API for the associated order and match by amount against the balance transaction. It’s not ideal since amount-based matching has its own edge cases (as you’ve already found), but combined with scoping to siblings under the same parent authorization it narrows the field considerably.

I’ll update this thread once I hear back from the team on this. Thanks again for flagging this!