Authorize.Net Accept.js vs Hosted Form vs Direct API

By E-commerce 4 Internet Marketers Editorial

Review. This article compares three Authorize.net checkout approaches that website owners and developers who sell regulated or high-risk products commonly evaluate. Accept.js (including the Accept.js hosted payment information form), Accept Hosted, and direct createTransactionRequest use of card or bank fields on the merchant server. Facts below are attributed to Authorize.net Accept.js, Accept Hosted, Accept suite, and Payment Transactions developer documentation, Authorize.net Support Center integration-method guidance, the Coalfire Authorize.net Accept SAQ Eligibility White Paper linked from Authorize.net docs, and Authorize.net’s Accept sample application notes on Cardinal Cruise with Accept.js. This is not legal, PCI, underwriting, or QSA advice. Final SAQ type for any merchant rests with that merchant’s acquiring bank and/or the payment brands. This article never invents PCI outcomes for a named merchant.

Facts. How Authorize.net frames the Accept suite versus the API

Authorize.net’s Accept documentation describes Authorize.net Accept as a suite of developer tools for building websites and mobile applications “without increasing PCI burden for merchants,” including JavaScript libraries, mobile SDKs, and hosted forms. The same page publishes a feature matrix that lists documented PCI compliance levels for Accept products when used as described.

Authorize.net Support Center article Integration Methods Explained positions modern options against obsolete AIM, SIM, and DPM paths. It describes the Authorize.net API (XML/JSON Payment Transactions and related features) as the replacement for AIM. Accept.js as the replacement for DPM that lets merchants use a custom payment form while submitting payment data to Authorize.net for a temporary token. And Accept Hosted as the replacement for SIM that requests a hosted payment token and embeds or redirects to a hosted form.

Authorize.net’s Payment Transactions documentation states that when developers integrate with the Authorize.net API they must consider PCI DSS, and points readers to Authorize.net PCI compliance materials. That page documents createTransactionRequest transaction types and settings. It does not itself publish an Accept-style SAQ matrix for merchants who post raw creditCard or bankAccount fields from their own servers.

Facts. Accept.js own form and Accept.js hosted payment information form

Authorize.net’s Accept.js documentation states that Accept.js is a JavaScript library that sends secure payment data directly to Authorize.net and returns a one-time-use payment nonce. The merchant then uses that nonce in a follow-on createTransactionRequest in place of payment data.

Accept.js documents two workflows.

Option 1. Host your own payment form for a PCI DSS SAQ A-EP solution with complete control of the customer payment experience. The merchant identifies form field IDs, intercepts submit, builds authData (API Login ID and Public Client Key) plus cardData or bankData, calls Accept.dispatchData, receives opaqueData (dataDescriptor and dataValue), clears sensitive fields, and submits the nonce to the merchant server.

Option 2. Embed Authorize.net’s hosted, mobile-optimized payment information form (AcceptUI) to collect card information in a PCI DSS SAQ A compliant way. The merchant page loads Accept.js after defining an AcceptUI button with required data-apiLoginID, data-clientKey, and data-responseHandler attributes. The customer opens the lightbox, submits card data to Authorize.net, and the script returns a nonce to the merchant response handler.

Documented Accept.js details that matter for checkout engineering include the following. Libraries must be loaded from Authorize.net servers (production and sandbox URLs differ). The page embedding Accept.js must use HTTPS. The payment nonce is valid for 15 minutes. opaqueData can be used anywhere the API accepts creditCard or bankAccount payment types, including one-time payments, Automated Recurring Billing subscription requests, and customer profile requests shown in the Accept.js guide. For the own-form path, Accept.js validates data types but does not authorize the card. Authorization happens later when the nonce is submitted in a transaction request. Own-form Accept.js supports payment card and eCheck.Net bank data objects. The Accept.js with UI path’s payment options default to showing credit card fields, with bank account fields off by default unless configured.

Authorize.net’s Accept feature matrix lists Accept.js as not hosting the payment form, SAQ A-EP, using your own payment form, supporting payment card and eCheck.Net. It lists Accept.js with UI as hosting the payment form (pop-up hosted fields on the merchant’s custom order form), SAQ A, and payment card support in that matrix column.

Facts. Accept Hosted payment form

Authorize.net’s Accept Hosted documentation describes Accept Hosted as a mobile-optimized payment form hosted by Authorize.net that enables use of the Authorize.net API for payment transactions while maintaining SAQ-A level PCI compliance. Merchants can redirect customers to the form or embed it in their page.

The documented workflow is as follows. Call getHostedPaymentPageRequest with transactionRequest and hostedPaymentSettings. Receive a form token valid for 15 minutes. Display the form by POSTing the token to the production URL https://accept.authorize.net/payment/payment or the sandbox URL https://test.authorize.net/payment/payment. The customer completes the form. Authorize.net processes the transaction. The customer returns to the merchant site via return URLs or iframe communicator messaging.

Accept Hosted documents three presentation modes. Full-browser redirect. Iframe/lightbox popup. Embedded iframe. Iframe modes require an HTTPS iframe communicator URL on the same domain as the parent page (hostedPaymentIFrameCommunicatorUrl). When the form is hosted in an iframe, merchants must set showReceipt to false to receive a response code through the communicator. Redirect mode always displays the receipt page. Redirect continue and cancel buttons send HTTP GET to the configured URLs without other transaction detail on that GET. Webhooks can still notify on approve or decline regardless of whether the customer clicks continue.

Documented customization is parameter-driven, not free-form HTML for card fields. Settings include return and cancel URLs, payment button text, accent color (hostedPaymentStyleOptions with bgColor), which payment options to show (card, bank, customer profile), CAPTCHA via hostedPaymentSecurityOptions, billing and shipping address visibility, email visibility, and order/receipt display options. Field required flags on the hosted form also interact with Merchant Interface Payment Form Form Fields settings. Unsent fields marked required in the Merchant Interface can cause transaction errors. Payment options can include customer profile selection when a customerProfileId is sent with the token request.

The Accept feature matrix lists Accept Hosted as Authorize.net hosting the payment form, SAQ A, not using your own payment form for card collection, and supporting payment card and eCheck.Net.

Facts. Direct API with card or bank fields on the merchant server

The same Support Center integration article describes the Authorize.net API as the modern path for payment transactions, customer profiles, recurring billing, fraud management, and transaction reporting using API Login ID and Transaction Key (with OAuth as alternative authentication support).

Accept.js documentation contrasts the nonce path with sending card details to the merchant server. Its workflow instructions require removing card payment data from the form so that data is not sent to the merchant server after tokenization. Support Center language for Accept.js states that it reduces PCI DSS burdens because the merchant never directly handles the card data, and that the API supports using the temporary token in place of actual payment data.

Payment Transactions documentation requires developers integrating the API to consider PCI DSS. Authorize.net’s Accept overview positions Accept products as tools to accept payments without increasing PCI burden relative to handling cardholder data on merchant-controlled collection paths. Authorize.net’s published Accept SAQ matrix covers Accept.js, Accept.js with UI, Accept Hosted, Accept Customer, and Accept Mobile SDKs. It does not list a parallel SAQ A or SAQ A-EP claim for merchants who collect raw card numbers on their own pages and POST them server-side in createTransactionRequest creditCard elements.

Facts. Documented SAQ eligibility language and its limits

Authorize.net’s Accept documentation points merchants to the Coalfire Authorize.net Accept SAQ Eligibility Overview and the more detailed SAQ Eligibility White Paper for SAQ eligibility information.

The white paper’s summary findings (assessment activities described for April 2017, document published September 2017) state that, with proper implementation using Authorize.net guidance and assuming no other method of accepting cardholder data is present, Accept Hosted and Accept UI could be eligible for SAQ A, and Accept.js could be eligible for SAQ A-EP. Assessor comments in that paper state that final approval of the appropriate SAQ type rests with the merchant’s acquiring bank and/or the payment brands, and that use of the product does not guarantee security or compliance.

Authorize.net’s live Accept.js and Accept Hosted feature pages repeat the SAQ A-EP (own form), SAQ A (Accept.js hosted payment information form), and SAQ A (Accept Hosted) language summarized above. Those pages do not remove the acquiring-bank approval caveat published in the Coalfire paper.

Facts. Customization and control compared

Accept.js own form. Authorize.net states developers have complete control over design and flow, and need only identify the payment elements Accept.js should process.

Accept.js with UI. Merchants control the surrounding order form. Authorize.net hosts the pop-up fields for card number, expiration, card code, and optionally name and postal code.

Accept Hosted. Authorize.net hosts the payment UX. Merchants configure behavior through hostedPaymentSettings JSON parameters and Merchant Interface form-field requirements, plus limited style accents such as button text and bgColor.

Direct API with merchant-hosted card fields. Merchants control the full HTML and server pipeline, including how and where card data is collected before createTransactionRequest. That control is exactly what Accept.js instructs merchants to avoid when the goal is keeping card data off the merchant server.

Facts. 3-D Secure related documentation near these paths

Authorize.net’s Accept sample application repository includes README-CardinalCruise.md. That file states that Authorize.net supports cardholder authentication through 3-D Secure, that Cardinal Commerce provides a JavaScript library (Cardinal Cruise) for consumer authentication, and that the sample demonstrates integrating Cardinal Cruise with Authorize.net Accept.js and the Authorize.net payment API. The documented sample sequence initializes Cardinal Cruise, retrieves a Cardinal JWT from the merchant server, starts consumer authentication, receives the Cardinal response, calls Accept.js to dispatch card data, then completes the payment.

The Accept Hosted feature documentation reviewed for this article describes form tokens, hosted payment settings, redirect and iframe presentation, receipts, AFDS held transactions, and communicator responses. It does not document a built-in Cardinal Cruise or 3-D Secure configuration parameter set on getHostedPaymentPageRequest.

Authorize.net API reference material for createTransactionRequest includes a cardholderAuthentication structure historically used to pass authentication indicator and cardholder authentication values from third-party cardholder authentication solutions for supported processors. API reference text marks that structure as deprecated and states it should not be used. Merchants evaluating current 3-D Secure submission fields should verify the live API Reference and their processor support rather than relying on deprecated field examples alone.

Interpretation. PCI scope optics for high-risk stacks

The following points are editorial interpretation grounded in the documented product differences above, not additional Authorize.net claims about any named merchant’s questionnaire result.

Interpretation. For regulated and high-risk catalogs, integration choice is often judged as part of underwriting and ongoing compliance narrative, not only as a developer convenience. Documented SAQ A pathways (Accept Hosted, Accept.js with UI) keep card collection on Authorize.net-hosted UI surfaces when implemented as documented. Documented SAQ A-EP (Accept.js own form) still sends card data from the browser to Authorize.net via merchant-controlled page script and form markup, which is a larger website-security questionnaire surface than SAQ A.

Interpretation. Direct API collection of raw card fields on merchant servers sits outside the Accept suite SAQ A / A-EP matrix Authorize.net publishes for Accept products. That does not invent a specific SAQ letter for any merchant. It does mean the Accept “without increasing PCI burden” framing does not apply the same way once cardholder data is accepted into merchant-controlled servers.

Interpretation. Acquirer final say matters more for specialty and high-risk approvals than marketing copy. Coalfire’s published caveat that acquiring banks and brands approve SAQ type is especially relevant when a stack mixes Accept Hosted for card entry with other channels that still touch card data.

Interpretation. Customization versus conversion control

Interpretation. Accept.js own form is the documented path when brand-consistent checkout, custom field layout, or specialized UX (age gates adjacent to payment fields, multi-step regulated disclosures, unusual shipping or license capture) must wrap the card inputs themselves. The tradeoff is SAQ A-EP scope and ownership of front-end script integrity, HTTPS, and form intercept correctness (including clearing PAN fields before postback).

Interpretation. Accept.js with UI and Accept Hosted trade visual control for SAQ A language in Authorize.net docs. Accept Hosted further moves decline and AFDS error display onto Authorize.net’s form, which can reduce custom decline UX work but also reduces control over retry messaging that high-risk sellers often tune carefully.

Interpretation. Direct API maximizes UI control and server-side orchestration. For high-risk operators, that control usually increases compliance cost and scrutiny unless a QSA and acquirer explicitly accept the architecture.

Interpretation. 3-D Secure and underwriting optics

Interpretation. The public Cardinal Cruise sample is anchored to Accept.js plus the payment API. Teams that need payer authentication should treat Accept.js plus a supported authentication integration as the path Authorize.net has demonstrated in that sample, and should ask Authorize.net or the acquirer how Accept Hosted fits current 3-D Secure requirements rather than assuming Hosted includes the same sample flow.

Interpretation. Underwriters reviewing high-risk applications often ask how card data is collected, whether CHD touches merchant servers, which SAQ the merchant completes, and whether strong customer authentication is available for relevant corridors. Documented Accept Hosted or Accept.js with UI architectures give a clearer “card fields never on merchant HTML” story. Accept.js own form gives a clearer “nonce only on server” story with A-EP questionnaire expectations. Direct raw-card API gives maximum flexibility and the weakest default PCI optics among the three.

Interpretation. None of those optics guarantee approval, lower reserves, or a specific SAQ outcome for any merchant. Specialty underwriting still weighs product category, processing history, chargeback ratios, fulfillment, and corporate structure alongside checkout architecture.

What remains unknown (verified gap list)

Authorize.net Accept Hosted docs reviewed here do not document a first-party 3-D Secure toggle equivalent to the Cardinal Cruise Accept.js sample. Current non-deprecated API fields for submitting EMV 3-D Secure results with createTransactionRequest should be confirmed in the live API Reference and with the merchant’s processor. The Coalfire white paper reflects a 2017 assessment. PCI DSS SAQ criteria continue to evolve, so merchants must confirm current questionnaire eligibility with their acquirer or QSA. This article does not invent PCI, 3-D Secure, or underwriting outcomes for any named merchant or vertical.

Authorize.Net Accept.js vs Hosted Form vs API for High-Risk Checkouts