Integration and Testing

[dnsBuffaloNY]

I got the Accept.Js working and it looks good (other than that annoying XmlHttpRequest 'No-Access-Control-Allow-Orgin' error)  It's cool because I can plug the returned nonce/token directly into the c# SDK and it works perfect simply by changing this code:

            /*  Not needed on server because we use the Accept.Js nonce/token
            var creditCard = new creditCardType
            {
                cardNumber = "4111111111111111",
                expirationDate = "0718",
                cardCode = "123"
            };
            */

            var creditCard = new opaqueDataType
            {
                dataDescriptor = "COMMON.ACCEPT.INAPP.PAYMENT",  // TODO: Don't hardcode this value
                dataValue = AcceptJSToken
            };

I like that the Credit Cards don't touch my server; All client side!

My question is regarding ACH payments: Will there be a future enhancement to AcceptJS to include Routing/account numbers so I can debit a bank account with the nonce/token?

Maybe that won't be part of AcceptJS;  I'm very new to online payments.  Perhaps my web site can collect the routing and account numbers, post back to my web server, and I call the Authorize.Net API to debit the bank account.  I don't plan on saving the routing/account  numbers (I'll use CIM). Do I need to worry about PCI compliance for bank routing/account numbers that post back to my server? Maybe just SSL/HttpS is all that is needed to collect bank account info?

Thanks for you feedback.  I'm real close to starting to integrate Authorize.Net into my production web site.

[RichardH Administrator]

Hello @dnsBuffaloNY

As mentioned in this previous post, Accept.js does not currently support ACH transactions.

I would suggest posting this as a new feature using our Ideas forum. This will allow others to vote on and make suggestions to improve the request.

Richard

[dnsBuffaloNY]

Thank you Richard.  

Enhancement request created:  https://community.developer.authorize.net/t5/Ideas/Include-ACH-in-Accept-Js/idi-p/55888

[Aaron]

Hi @dnsBuffaloNY,

This doesn't address the ACH questions, but I wanted to point out that the "No Access-Control-Allow-Origin" error has been fixed.

For anyone else watching this thread, we've released code in sandbox that fixes this and other issues, and this code should make it into the production environment within the next couple of days.

Specifically for Accept.js, there's no longer any "Access-Control-Allow-Origin" related error in the console, the accept.js script can now be loaded at any point in the workflow, and the response handler function can be passed directly in the function call instead of having to pass the name.

Of course, please let us know if anything's not working as expected!

[Aaron]

For anyone watching this thread, we've enhanced Accept.js to be able to return a payment nonce incorporating bank account information (for eCheck) instead of just card information. This payment nonce can then be used in exactly the same way as any card-originated payment nonce.

The Accept.js documentation hasn't been updated to reflect this yet, but will in the next couple of weeks. In the meantime, the request works just like the sample code below. You submit a bankData object instead of a cardData object, and the bankData object contains four required parameters. accountType can be either checking, savings, or businessChecking.

var secureData = {}, authData = {}, bankData = {};
	
	bankData.routingNumber = document.getElementById('ROUTINGNUMBER_ID').value;
	bankData.accountNumber = document.getElementById('ACCOUNTNUMBER_ID').value;
	bankData.nameOnAccount = document.getElementById('ACCOUNTNAME_ID').value;
	bankData.accountType= document.getElementById('ACCOUNTTYPE_ID').value;

	secureData.bankData = bankData;

	authData.clientKey = 'my_client_key';
	authData.apiLoginID = 'my_api_login_id';
	secureData.authData = authData;
	
	Accept.dispatchData(secureData, 'responseHandler');

[czigor]

Hi, 

Thanks for this info! We were trying to implement eCheck and changed only the above fields. That is, we still send a createCustomerProfileRequest request, just like we would do in a traditional accept.js request. For that however we get an "Error from Authorize.net: E00014: Card Number is required.#012E00014: Expiration Date is required." error response.

Is createCustomerProfileRequest still the proper request for eChecks? Or should we use something else?

Any help would be appreciated.

Andras

[Aaron]

HI @czigor,

Thanks for the report. We're currently investigating this. Hopefully I can provide some clarification or a workaround soon.

[Aaron]

Hi @czigor,

My sincere apologies, but an Accept payment nonce that contains bank data can only be used for payment transactions at this time. It can't be used for creating a profile or creating a subscription.

This will be fixed, but I have no information on the timeframe for fixing this.

I apologize that this particular limitation wasn't available in my original announcement. I was passing on the information I was given.

To work around this in your particular case, about the only thing I can recommend is to use the payment nonce to do an initial transaction, then use the createCustomerProfileFromTransactionRequest method to create a profile using the information that was used in the initial transaction.

More specifically:

1. Use the nonce to do an initial transaction of type "authOnlyTransaction", for $0.01. (While you could do a zero dollar auth only transaction, a zero dollar transaction couldn't be used as the basis for profile creation.)

2. Assuming success of step 1, do a createCustomerProfileFromTransactionRequest, referencing the transaction ID returned in step 1.

3. Do a void request of the transaction in step 1.

[czigor]

Thanks Aaron,

SInce eChecks are not reusable anyway, we just did it using https://developer.authorize.net/api/reference/index.html#payment-transactions-create-an-accept-payme... directly. So no createCustomerProfileFromTransactionRequest  and authorization-void transactions. 

It seems to be working, thanks for the clarification on what we can expect!

Best

Andras

[Aaron]

Hi András,

Glad it's working for you! Let me know if there's anything else I can do.