We are a payment platform submitting recurring subscription charges via the Authorize.net API using Customer Profiles (customerProfileId + paymentProfileId).
Our downstream processor (Ecrypt, MID XXXXXXXX) reports that recurring Merchant-Initiated Transactions (MIT) are arriving with:
- POS Entry Mode 01 (Keyed) or 81 (Internet/E-commerce)
Instead of: - POS Entry Mode 10 (Credential on File)
This is causing Mastercard data integrity violations and Visa stored credential compliance exposure.
What we currently send on recurring charges:
{
"transactionRequest": {
"transactionType": "authCaptureTransaction",
"amount": "29.99",
"profile": {
"customerProfileId": "xxx",
"paymentProfile": {
"paymentProfileId": "yyy"
}
},
"subsequentAuthInformation": {
"originalNetworkTransId": "ABC123456789"
}
}
}
What we do NOT currently send:
{
"transactionRequest": {
"processingOptions": {
"isSubsequentAuth": "true"
}
}
}
And on the initial (first) subscription charge, we do not send:
{
"transactionRequest": {
"processingOptions": {
"isFirstRecurringPayment": "true"
}
}
}
Questions:
1. Will adding processingOptions.isSubsequentAuth = true on subsequent recurring charges cause Authorize.net to send the correct Stored Credential / COF indicators to the card networks, resulting in POS Entry Mode 10 at the processor?
2. Should we also set processingOptions.isFirstRecurringPayment = true on the initial subscription charge to properly establish the COF relationship?
3. Is subsequentAuthInformation.originalNetworkTransId sufficient alone, or must it be paired with processingOptions.isSubsequentAuth for the processor to receive correct MIT/COF flags?
4. Are there any other fields we should include for full Visa/Mastercard stored credential compliance when charging Customer Profiles for recurring subscriptions?
Reference Documentation:
We are using authorizenet Node.js SDK via createTransactionRequest
