Bug in Accept Suite not binding transaction to customerProfileId after adding another/new credit card

Question

I am using Authorize.net's hosted Accept Suite on my client portal. When the user opens an invoice, an auth token is generated and embedded into the payment page. The user then clicks PayNow and an iFrame pops up with a form for the user to enter their CC info. The form itself is generated by Authorize.net's JS.

If the client is new, after the payment is made we then use createCustomerProfileFromTransaction call to create a new customerProfile (on Authorize.nets CIM) and store both the customerProfileId and paymentProfileId in our customer db records.

The next time the client needs to make a payment, we generate a new auth Token in the payment page that includes customerProfileId - the iFrame then pops up showing the clients stored CC to use again. The client can just select that payment method and complete the transaction. So far, everything works as expected.

However, if the user decides to enter a new credit card, not using the one already on profile, then this is where the bug reveals itself. The user adds the new card info and submits the payment. If the payment is successful then the new card gets added as a new paymentProfile. When we login to the authorize.net portal and view the customerProfile, we can see both the old paymentProfileId and the newly created one....so far, all is good. However, when we look at the customer payment history - the transaction cannot be found under the customerProifle. If we do a general search for the transactionID we can find it, but its not bound to the customer - its like a ghost transaction that has no owner.

The customerProfileId is not a part of the transaction so there is no way of knowing that transaction belongs to that customer.

When we create the auth token with the customerProfileId - we know the customerProfileId is successfully being passed. #1 - the clients previous payment profile is displayed in the pop up payment form and #2 - the new card successfully adds a new paymentProfile to the proper customerProfileId. But the transaction is left out in limbo.

Authorize.net needs to fix this bug by binding the same transaction, that successfully created the new paymentProfile, to the customerProfileId.