Authorize.net and google pay?

I want to add a Google Pay “Pay Now” button to my Zen Cart website. I would prefer not to use Braintree or Square because I currently use Authorize.Net as my payment gateway and really don’t want to switch gateways.

My Zen Cart websites are currently using the Authorize.Net AIM payment module. While researching Google Pay integration, I discovered that Authorize.Net AIM is now deprecated and is being phased out.

Is there a current, up-to-date Authorize.Net payment plugin available for Zen Cart that uses the newer Authorize.Net API instead of the legacy AIM integration?

Ideally, I would like to continue using Authorize.Net for regular credit card payments while also adding Google Pay to the checkout.

Does anyone have any suggestions or feedback that can assist me?

chadlly2003:

I want to add a Google Pay “Pay Now” button to my Zen Cart website. I would prefer not to use Braintree or Square because I currently use Authorize.Net as my payment gateway and really don’t want to switch gateways.

My Zen Cart websites are currently using the Authorize.Net AIM payment module. While researching Google Pay integration, I discovered that Authorize.Net AIM is now deprecated and is being phased out.

Is there a current, up-to-date Authorize.Net payment plugin available for Zen Cart that uses the newer Authorize.Net API instead of the legacy AIM integration?

Ideally, I would like to continue using Authorize.Net for regular credit card payments while also adding Google Pay to the checkout.

Does anyone have any suggestions or feedback that can assist me?

https://docs.zen-cart.com/user/payment/authorizenet_cim/

Both the commercial Square mod and PayPal RESTful can accept Google Pay and Apple Pay, and don't charge monthly fees.

Both have fees similar to AuthorizeNet, and even with the cost of the commercial Square mod, you'd pay 50% per year less than the AuthorizeNet monthly fees

dbltoe:

Both the commercial Square mod and PayPal RESTful can accept Google Pay and Apple Pay, and don't charge monthly fees.

Both have fees similar to AuthorizeNet, and even with the cost of the commercial Square mod, you'd pay 50% per year less than the AuthorizeNet monthly fees

Thanks for the feedback. After doing some additional research, I found that Authorize.net now considers SIM obsolete and is phasing it out.

Is Zen Cart planning to update its Authorize.net payment modules to support Authorize.net's newer payment options and features?

I was surprised to learn that both of the Authorize.net (AIM/CIM) modules currently available in Zen Cart are both being phased out. Since I would prefer to continue using Authorize.net as my payment gateway, this seems to leave me with very limited options going forward.

Are there any plans for an updated Authorize.net module that will support the current API and newer features such as Apple Pay and Google Pay?

The customer is adamant about continuing to use Authorize.net as their payment gateway. So i am going to try and dig a little deeper to see if i could come up with a better solution.

I see there is a difference from SIM and the link lat9 shows which is CIM which is the most up to date version. Not sure why i made that so confusing for myself.

Everything available in Zen Cart right now for AuthorizeNet is at least two years old and does not match their current APIs. That's why you will see the advice to use carlwhat's version. It is reporting ZC 2.0.0.

I am building the basic mod now to use the new system, which should be compatible with versions 1.5.8 to 3.0.0 and PHP 7.4 to 8.5. That's a good cross-section to cover most stores today. Although it's an encapsulated plugin, I will include files that allow users on 1.5.8 - 2.0.0 to use it. (Those versions do not load payment modules as a norm.)

AuthorizeNet currently has three programs:

Gateway Only (your own merchant account) is $25/month plus $0.10 per transaction and a $0.10 daily batch fee.
All-in-One (their merchant account) is $25/month with 2.9% and $0.30 per transaction. No batch fee.
Gateway Plus eCheck (their add-on for checks) costs an extra $25/month plus $0.75 per check processed.

Unfortunately, the version you need will be a commercial one that includes Google Pay and Apple Pay. It will also be able to use "card on file," although it will only store a token that AuthorizeNet recognizes.

If there are enough interested, I may put together a POS version as well.

Anyone can get the files needed for what I am building as a free (and hopefully incorporated) plugin. The steps for adding the other functions involve hours of work and registering for specific access with Google ($??) and Apple ($99 minimum).

Hopefully, I can recoup enough to eventually follow in lat9's footsteps and add it in, as she did with POSM.

The plugin submissions are currently experiencing hiccups. I'll post back here and a new support thread when the mod's on GitHub

The new module for AuthorizeNet_Accept_Payments is now available on GitHub and myZenCartZone.com.

It will work with ZC 1.5.8-3.0.0 and PHP 7.4-8.5. It uses the latest AuthorizeNet APIs.

The support thread is located at https://www.zen-cart.com/threads/207341

dbltoe:

The new module for AuthorizeNet_Accept_Payments is now available on GitHub and myZenCartZone.com.

It will work with ZC 1.5.8-3.0.0 and PHP 7.4-8.5. It uses the latest AuthorizeNet APIs.

The support thread is located at https://www.zen-cart.com/threads/207341

I am going to try and use AuthorizeNet_Accept_Payments because i dont want to save any credit card info. Just looking to add the paypal and google buttons. I will document and let you know where I stand in a few days

I decided to go with AuthorizeNet_Accept_Payments. Seem like the best option for me. I created a google button and it seems to work well. If anyone has any insight on what I have done so far that would be great. Attahched is the google button that has been completed for this module. Tomorrow Ill work on the Apple button

Nice work, and quickly done. The notifier hooks and the hidden token fields in Accept.js Payments were put there for exactly this, so it's good to see them used.

Before anyone drops it into a store, a few things won't work yet, so nobody loses an afternoon to them:

1. Standard checkout. The add-on only works with One Page Checkout. The plugin's own Continue handler passes a submission through only when it tokenizes the card itself, so on the standard checkout, a Google Pay token gets stopped with "enter your card number." Version 1.0.1 of the plugin (coming soon) adds a proper wallet hook to that script; until it's out, this add-on is OPC-only.

2. gatewayMerchantId. It has to be the account's Payment Gateway ID (Merchant Interface > Account > Merchant Profile), not the API Login ID. The wrong value results in an "Invalid ownership" error from Authorize.Net. The token itself goes to the gateway Base64-encoded, which the add-on does correctly.

3. Test mode only. TEST, country US, and the card networks are fixed in the file. Production needs a merchant ID from the Google Pay & Wallet Console and Google's approval of the domain, along with checkout screenshots, none of which the add-on includes.

4. The total. The amount is read when the payment page renders. On OPC, picking a shipping method after that leaves the Google Sheet on the old total; the add-on then quietly drops the stale token, and the customer has to press the button again.

5. Apple Pay is a different job. A button isn't enough: it needs an Apple Developer membership, a merchant identity certificate, and a server-side merchant validation call to Apple on every payment.

As mentioned above, the Pro edition with Google Pay, Apple Pay, and card-on-file, with settings in the admin and production support, is in the works.

dbltoe:

Nice work, and quickly done. The notifier hooks and the hidden token fields in Accept.js Payments were put there for exactly this, so it's good to see them used.

Before anyone drops it into a store, a few things won't work yet, so nobody loses an afternoon to them:

1. Standard checkout. The add-on only works with One Page Checkout. The plugin's own Continue handler passes a submission through only when it tokenizes the card itself, so on the standard checkout, a Google Pay token gets stopped with "enter your card number." Version 1.0.1 of the plugin (coming soon) adds a proper wallet hook to that script; until it's out, this add-on is OPC-only.

2. gatewayMerchantId. It has to be the account's Payment Gateway ID (Merchant Interface > Account > Merchant Profile), not the API Login ID. The wrong value results in an "Invalid ownership" error from Authorize.Net. The token itself goes to the gateway Base64-encoded, which the add-on does correctly.

3. Test mode only. TEST, country US, and the card networks are fixed in the file. Production needs a merchant ID from the Google Pay & Wallet Console and Google's approval of the domain, along with checkout screenshots, none of which the add-on includes.

4. The total. The amount is read when the payment page renders. On OPC, picking a shipping method after that leaves the Google Sheet on the old total; the add-on then quietly drops the stale token, and the customer has to press the button again.

5. Apple Pay is a different job. A button isn't enough: it needs an Apple Developer membership, a merchant identity certificate, and a server-side merchant validation call to Apple on every payment.

As mentioned above, the Pro edition with Google Pay, Apple Pay, and card-on-file, with settings in the admin and production support, is in the works.

I got the the google button working it wasn't too bad with your plugin. Everything seems to be working correctly in all my test.

I am working on the Apple Button Today. **note it takes a few days to get approved.

Once I get that completed I will post both the google and apple pay buttons files so other people can use if if needed

***Note: i AM USING OPC

chadlly2003:

dbltoe:

Nice work, and quickly done. The notifier hooks and the hidden token fields in Accept.js Payments were put there for exactly this, so it's good to see them used.

Before anyone drops it into a store, a few things won't work yet, so nobody loses an afternoon to them:

1. Standard checkout. The add-on only works with One Page Checkout. The plugin's own Continue handler passes a submission through only when it tokenizes the card itself, so on the standard checkout, a Google Pay token gets stopped with "enter your card number." Version 1.0.1 of the plugin (coming soon) adds a proper wallet hook to that script; until it's out, this add-on is OPC-only.

2. gatewayMerchantId. It has to be the account's Payment Gateway ID (Merchant Interface > Account > Merchant Profile), not the API Login ID. The wrong value results in an "Invalid ownership" error from Authorize.Net. The token itself goes to the gateway Base64-encoded, which the add-on does correctly.

3. Test mode only. TEST, country US, and the card networks are fixed in the file. Production needs a merchant ID from the Google Pay & Wallet Console and Google's approval of the domain, along with checkout screenshots, none of which the add-on includes.

4. The total. The amount is read when the payment page renders. On OPC, picking a shipping method after that leaves the Google Sheet on the old total; the add-on then quietly drops the stale token, and the customer has to press the button again.

5. Apple Pay is a different job. A button isn't enough: it needs an Apple Developer membership, a merchant identity certificate, and a server-side merchant validation call to Apple on every payment.

As mentioned above, the Pro edition with Google Pay, Apple Pay, and card-on-file, with settings in the admin and production support, is in the works.

I got the the google button working it wasn't too bad with your plugin. Everything seems to be working correctly in all my test.

I am working on the Apple Button Today. **note it takes a few days to get approved.

Once I get that completed I will post both the google and apple pay buttons files so other people can use if if needed

***Note: i AM USING OPC

okay guys google pay seems to be working well with AuthorizeNet_Accept. I have it live and tested all is good. I have enclosed the final google pay add on if someone else wants to add google pay to autorize.net checkout.

Once I get a approved from apple i will post the files upon completion. Too be continued....

Final follow-up. Apple and google buttons are working with Authorize.net and zencart. This plugin AuthorizeNet_Accept_Payments save me a lot of time and effort. Enclosed are the files need to get the buttons working.

**note: getting approved by apple and google is a headache. Once you get past that part the rest is easy.

Re: AuthorizeNet Accept Payments

Thanks for both of these.

The invoice number: you're right, and it's our bug, not something on your side. The module reads the orders table's Auto_increment through SHOW TABLE STATUS, and on MySQL 8 that value comes from a statistics cache that refreshes once a day by default, so the base number repeats. Our test stores run MariaDB, which reads it live, so we never saw it. The random suffix keeps every invoice unique, so no transaction was affected; only the number was misleading. Your replacement is what the core AIM module does, and 1.0.2 will ship the same query, so nobody needs to patch a file. Please install 1.0.2 rather than editing v1.0.0 once it's up, since the edit will be lost on the next upgrade.

The Apple Pay and Google Pay add-ons: we went through both the way we check our own packages before a release. The gateway side is correct. Three things to fix before anyone runs them on a live store. The Apple session page accepts a POST from anyone with no session token or AJAX header, so any visitor can make the store open sessions to Apple with your merchant certificate; check $_SESSION['securityToken'] and the X-Requested-With header first. Its host rule also refuses cn-apple-pay-gateway.apple.com and the pod hosts (apple-pay-gateway-nc-pod1.apple.com and so on) that Apple lists on its server setup page and does hand out, and initiativeContext should be the request host rather than a typed-in domain. And both scripts write the module's hidden fields directly and keep their own copy of the token; 1.0.1 added window.authorizenet_accept.setWalletToken() and an authorizenet_accept:ready event so the module handles persistence across OPC redraws, drops the token when the customer edits the card fields, and lets the submit through. As they stand, approve Google Pay, change your mind, type a card within 15 minutes, and the wallet token still gets charged. The full contract with an example observer is in docs/CUSTOMIZING.md in the package.

If you'd rather keep the add-ons in your own thread, that keeps this one about the module itself, but either way, thank you for the report

_______________________________________________________________

I made the scruity changes this should be good now.