I'm looking to assess (a bit tardy, I know) some testing scenarios for my team as we begin augmentation of our existing Express API integration with respect to the Credential on File (CoF) functionality. As it's our understanding, the NetworkTransactionId will need to be persisted along with our existing PASS "token" information (PaymentAccountID). This is all fine and good, but we're going to need some clarification on what happens if an invalid NetworkTransactionId is submitted on any subsequent request(s) through the API/network. For example, a CreditCardSale is issued using PASS with the last NetworkTransactionId and appropriate submission/payment type, and a successful response returned with a new NetworkTransactionId. However, due to some unforeseen event, our system is unable to persist this new value (database connection drop, unrelated application crash, etc.). What would happen on the next transaction using PASS and the previous NetworkTransactionId? Would the transaction be declined, or would there simply be a "downgrade"?
Frank,
If you happen to lose the most recent / current NetworkTransactionID, you're welcome to fall back to the most recent one you have stored.
If the transaction declines using a "used" NetworkTransactionID, or if you happen to lose the NetworkTransactionID altogether, you can flag the next transaction as an Initial payment (SubmissionType=1) and re-start the chain of NetworkTransactionID's.
We don't have any concrete information on the repercussions of misusing COF fields. To our understanding, card issuers who are actively tracking COF might decline a transaction that falls outside of expectations. There should be no downgrades, fines, or penalties. That said, given that the mandate is brand new and adoption has been slow, we don't have many reports from merchants who are using it, to see how different scenarios are being handled by the card issuers.
As much as I would like to give you a hard-and-fast answer, in this case we'll probably need to learn together over time.