Authorize.Net is a card payment gateway based in the US. If you run an auction, raffle or prize site on PrizeX, BidKing or RaffKing, the Authorize.Net gateway is already in your copy. Its card form sits on your own payment page and uses Authorize.Net's Accept.js, so it needs three keys, not two. This guide covers which key goes where, how to test, and what the setup means for your PCI scope.
Who has it
- Authorize.Net is included in every edition: BidKing Starter, Plus and Pro, PrizeX and RaffKing. It's one of the 10 ready-to-use gateways, not an add-on.
- You need your own Authorize.Net account. Payments go to that account, not through us.
- Only the store's Administrator can change its keys and mode. Other staff with access to settings see which keys are set, not what they hold.
How an Authorize.Net payment works
- The buyer chooses Authorize.Net on your payment page, and a card form opens on your site: Card number, Expiry (MM/YY) and Security code (CVV).
- Accept.js sends the card details from the buyer's browser to Authorize.Net, which hands back a one-use token.
- Only that token is posted to your server. Your server charges it through Authorize.Net, for the amount of the payment request it already holds, not an amount sent from the browser.
- The payment is credited once Authorize.Net approves it. A payment Authorize.Net holds for fraud review isn't credited, and approving it in Authorize.Net doesn't complete the order: the buyer is told it's held for review, and you check it in Authorize.Net and settle or refund it yourself.
If anything posts card details to your server instead, such as a payment page left open from before the gateway moved to Accept.js, the post is refused and nothing is charged. The buyer is asked to enter the card again on the current form.
The three keys, and where each comes from
On the gateway's settings page, under Keys, there are three boxes. Each one's hint says where to find it in your Authorize.Net account:
| Box | What it's for | Where the hint says to find it |
|---|---|---|
| API Login ID | Your server signs in to Authorize.Net with it to charge the token. The card form uses it too. | Account › Settings › Security Settings › API Credentials & Keys |
| Transaction Key | The secret your server signs in with. Once saved it isn't shown again. | Account › Settings › Security Settings › API Credentials & Keys |
| Public Client Key | Accept.js uses it in the buyer's browser to turn the card into a token. | Account › Settings › Security Settings › Manage Public Client Key |
Menu names in the Merchant Interface are Authorize.Net's to change. If you can't find one, look in your Merchant Interface's security settings, or ask Authorize.Net.
Entering them in your store
- Open Settings › Payment Gateways, find Authorize.Net and click Edit keys and settings.
- Under Keys, paste your API Login ID, Transaction Key and Public Client Key. The Transaction Key box shows empty after you save; leave it empty later to keep the saved key.
- Set the Mode to match your keys (see below), and check the Currency.
- Save, then switch it on from the Payment Gateways list. It's installed switched off, and it can't be shown at checkout until all three keys are filled in. Until then its page says "Checkout can't use Authorize.Net until" the missing keys are filled in.
Test and live
The Mode on the gateway's page decides which Authorize.Net service your store talks to. Test mode uses Authorize.Net's sandbox, so no real money moves; Live payments uses its live service. It's installed set to Live payments. As the page puts it: "Use the test keys from its dashboard while in it."
Sandbox keys and live keys don't cross over: sandbox keys work only in Test mode, and live keys only in Live payments. When you go live, change the Mode and replace all three keys with your live ones, then make one small real payment to check.
Until the Public Client Key is in
A store that had Authorize.Net switched on before its card form moved to Accept.js may have the first two keys but no Public Client Key. Until you enter it:
- Buyers don't see Authorize.Net at checkout, so they can't start a payment that would fail.
- The admin shows a warning on the dashboard, the payment gateways list and Authorize.Net's own settings page, to staff who can manage settings. It says Authorize.Net "is switched on, but buyers can't pay with it: card payments now go through Authorize.Net's secure Accept.js form, which needs your Public Client Key." Open settings takes you to the gateway's page.
- Payments already made or in flight keep settling.
Use HTTPS
Buyers type their card details into a form on your own payment page, so run your store on https:// before you switch Authorize.Net on. As the admin puts it, Authorize.Net's Accept.js card form "only works on a secure (https://) page, so buyers can't pay by card" otherwise.
While Authorize.Net is switched on and your store isn't on https://, the same places show a second warning, to staff who can manage settings. The store goes by Settings › General › Site URL when it's set, and otherwise by the address you opened the admin on. Install an SSL certificate for your domain, then set Site URL to its https:// address; Open General settings takes you there.
What Accept.js means for your PCI scope
Card details go from the buyer's browser to Authorize.Net through Accept.js, and your store gets a one-use token to charge. Because the card form is on your own payment page, that puts your store in PCI SAQ A-EP. Your payment provider or a PCI assessor can confirm which questionnaire applies to your business, and what else it asks of your server and your pages.
Currencies
Authorize.Net charges in the gateway's own Currency. The gateway's page accepts US dollars (USD), Canadian dollars (CAD), pounds (GBP), euros (EUR), Australian and New Zealand dollars (AUD, NZD), Swiss francs (CHF), Danish and Norwegian kroner (DKK, NOK), Polish złoty (PLN) and Swedish kronor (SEK). Each Authorize.Net account takes the currency its processor settles in, so check yours with Authorize.Net.
If the gateway's currency isn't your store's, the amount is converted at the Exchange Rates plugin's saved rate if it's less than a day old, otherwise at the Fixed rate you set on the gateway's page. With neither, Authorize.Net is hidden at checkout rather than charging a guessed amount.
Late payments and refunds
If Authorize.Net approves a payment after its payment request has failed or expired, nothing is credited. With kernel 1.1.478 or later (the current release has it), the payment is listed under Payment Requests › Paid, not ordered for you to refund or fulfil. The buyer goes to the payment failed page rather than being told it worked.
Refunds are made in your Authorize.Net account. The gateway doesn't send refunds to Authorize.Net from your admin. On the order, either record the refund with its Authorize.Net reference, or refund to the buyer's wallet instead.
Check with Authorize.Net about your business
Card processors review what a business sells before they take it on. If your site sells raffle tickets, paid entries or game plays, tell Authorize.Net when you apply and get their approval before you rely on it. Whether your site needs a licence where you operate is a separate question: you're responsible for that, so check with a local lawyer.
What it doesn't do
- a hosted payment page on Authorize.Net's site (the card form is on your payment page);
- refunds from your admin;
- subscriptions, recurring payments or saved cards;
- eCheck or bank account payments;
- charging in several currencies at once (one currency, converted if needed).
Setting up payments for an Indian audience instead? See our Razorpay guide.
Common questions
Where do I find the Public Client Key?
In the Authorize.Net Merchant Interface. The gateway's own settings name the place: Account › Settings › Security Settings › Manage Public Client Key. Enter it under Public Client Key on the gateway's settings page.
Why isn't Authorize.Net showing at checkout?
Usually a key is missing. It can't be switched on until the API Login ID, Transaction Key and Public Client Key are all filled in, and while it has no Public Client Key it's left off checkout. A currency with no exchange rate hides it too.
Can I use my sandbox keys on the live store?
No. Test mode talks to Authorize.Net's sandbox and Live payments to its live service, so use sandbox keys in Test mode and live keys in Live payments.
Which PCI questionnaire does this put my store in?
Card details go from the buyer's browser to Authorize.Net through Accept.js, and your store gets a one-use token to charge. Because the card form sits on your own payment page, that puts your store in PCI SAQ A-EP. Your payment provider or a PCI assessor can confirm what applies to your business.