Details
Improvement
Major
Description
Problem
Authorize.Net CIM allows ACH and CC to be stored offsite. However, their API returns an error attempting to create new customer or payment profiles if they detect a duplicate. See https://support.authorize.net/authkb/index?page=content&id=A116&pmv=print
API docs:
https://developer.authorize.net/api/reference/#customer-profiles-get-customer-profile-ids
i.e.:
| Function | Fields Used For Duplicate Profile Verification |
|---|---|
| createCustomerProfileRequest | merchantCustomerId description |
| createCustomerPaymentProfileRequest | customerProfileId cardNumber accountNumber routingNumber billToFirstName billToLastName billToAddress billToZip |
| createCustomerShippingAddressRequest | customerProfileId firstName lastName address zip phoneNumber |
If one of the above functions is submitted, and if the fields used for duplicate profile verification contain the exact details as an existing profile, E00039 will occur.
Note: The error response will include the ID number of the duplicate profile.
Example error response
<createCustomerProfileResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <messages> <resultCode>Error</resultCode> <message> <code>E00039</code> <text>A duplicate record with ID 1220992516 already exists.</text> </message> </messages> <customerPaymentProfileIdList /> <customerShippingAddressIdList /> <validationDirectResponseList /> </createCustomerProfileResponse>
If an error occurs, the profile ID is returned, albeit in a text message we would have to parse (note: unreliably) and use to re-attempt storage.
Changes
Current behavior
When storing a CC or ACH account, we currently:
- Attempt to create the customer profile (if we can't re-use one we already have)
- Attempt to create a new payment profile for the account details
- Return the customer profile ID and payment profile ID (which will be stored with the Payment Account in Blesta)
New behavior
This has to be updated to:
- Attempt to create the customer profile (if we can't re-use one we already have)
- Look for error E00039
- Parse the text message E00039 for customer profile ID
- Set the parsed profile ID as the customer profile ID for creating the payment profile
- Attempt to create a new payment profile for the account details
- Look for error E00039
- Parse the text message E00039 for payment profile ID
- Set the parsed profile ID as the payment profile ID for the account
- If either profile currently exists (i.e. we are not adding them new), then we must update the profiles (see AuthorizeNetCim::update, ::updateProfile, ::updatePaymentProfile)
- Only on success, return the customer profile ID and payment profile ID (which will be stored with the Payment Account in Blesta). On failure, return false
Activity
What would be the alternative?
Paul Phillips
added a comment - What would be the alternative? Do we really want to ignore when the payment account already exists? In this way we could have multiple payment accounts in Blesta being paired with the same Authorize.net payment profile.
This has been reported by some customers lately. If the client deletes an existing payment account before creating a new one then they are unable to create a new one and staff needs to log into authorize.net and delete the profile first.
Paul Phillips
added a comment - This has been reported by some customers lately. If the client deletes an existing payment account before creating a new one then they are unable to create a new one and staff needs to log into authorize.net and delete the profile first. 
To just not allow you to submit payment credentials that already exist in Authorize.net. But I actually ended up implementing a fix with the best of both worlds that will reject the duplicate if it exists in Blesta, but link it up instead if it only exists in Authorize.net.