Integration and Testing

[EarlGray47]

I’m using Accept Hosted to handle donations given online for a non-profit entity. I’m currently trying to add support for recurring gifts, which I intend to handle as ARB subscriptions. In view of maintaining PCI compliance, I’m using Accept Hosted to avoid storing or having access to any credit card data (other than the last four digits that Authorize.Net allows users of the backend to see).

Right now I’m following these steps for recurring transactions

1. Send through a one-time transaction using Accept Hosted and note the transaction id of said transaction (see forum post here):
2. Get a user id for the user currently logged into the site (I use Community Builder Login for this) and check for a Customer Profile Id in Authorize.Net’s records that matches the user id.
3. If such a Customer Profile Id exists in Authorize.Net’s records, note that customer profile id and skip to step 5.
4. If a customer profile doesn’t already exist, call createCustomerProfileFromTransaction(), passing in the transaction id from step 1. Note the customer profile id from the just-created customer profile.
5. Call getCustomerProfile(), passing in the customer profile id (either from step 3 or step 4). This gives me the CP information I need to move forward.

This works great as long as the donor sticks with the same credit card (e.g., XXXX1111). The customer payment profile is created automatically in the createCustomerProfileFromTransaction() call along with the customer profile. However, if the donor tries to submit another gift with a new credit card (e.g., XXXX8888), the transaction still goes through with the old credit card number (such as XXXX1111), not the new number as expected.

I’m creating the customer payment profile with the createCustomerProfileFromTransaction() call because that’s the only way I can see to create a payment profile from a transaction without inputting the credit card number. Unfortunately, createCustomerProfileFromTransaction() is only called on a first-time donation so a new payment profile isn’t created on any subsequent gifts, even if a new credit card is used.

A few possible solutions I’ve looked into:

• Finding an API call that allows me to create a payment profile from a transaction. Based on the forum post here, it would seem that such an API call doesn’t exist.
• Finding other API methods that allow me to create a payment profile. Unfortunately all of them require me to input credit card information, which isn’t helpful for PCI compliance.
• Creating a new customer profile for each transaction and linking all related customer profiles to the user id (from Community Builder Login) of the logged-in user. This seems unnecessarily complicated, as I might have to match several customer profiles to one user.

Any help/advice? Thanks in advance.

[EarlGray47 · Accepted solution]

Solution:
- Set up the first ARB subscription by adding a transaction and subsequently calling createSubscriptionFromCustomerProfile(), passing in the active customer profile, the associated customer payment profile, and relevant transaction information (not card data, which I can't access other than the last 4 digits of the card #).
- For additional ARB subscriptions, display the list of payment profiles with the limited information I can get from the API. Allow the user to select the payment profile they desire or to create a new payment profile.
- If a new payment profile needs created, get a token with GetAcceptCustomerProfilePage and use that token to display an Authorize.net hosted embedded iFrame. Add the payment profile using this iFrame. In this way, I can avoid storing card data.
- On submission of a 2nd (or 3rd, 4th, ...) ARB subscription, call createSubscriptionFromCustomerProfile() again, passing in the active customer profile, the associated customer payment profile, and relevant transaction information (not card data).

[EarlGray47 · Accepted solution]

Solution:
- Set up the first ARB subscription by adding a transaction and subsequently calling createSubscriptionFromCustomerProfile(), passing in the active customer profile, the associated customer payment profile, and relevant transaction information (not card data, which I can't access other than the last 4 digits of the card #).
- For additional ARB subscriptions, display the list of payment profiles with the limited information I can get from the API. Allow the user to select the payment profile they desire or to create a new payment profile.
- If a new payment profile needs created, get a token with GetAcceptCustomerProfilePage and use that token to display an Authorize.net hosted embedded iFrame. Add the payment profile using this iFrame. In this way, I can avoid storing card data.
- On submission of a 2nd (or 3rd, 4th, ...) ARB subscription, call createSubscriptionFromCustomerProfile() again, passing in the active customer profile, the associated customer payment profile, and relevant transaction information (not card data).