When merchants approach me to integrate or rebuild Authorize.Net for their store, the conversation almost always boils down to a technical crossroads: Accept Hosted vs Accept.js in PrestaShop. Many store owners assume payment gateways are plug-and-play components, but choosing the wrong integration architecture can saddle your business with painful PCI compliance audits, broken one-page checkouts, or unexpected cart drop-offs.
Authorize.Net retired older, direct-server methods like AIM (Advanced Integration Method) years ago to keep raw cardholder data completely off merchant servers. In modern PrestaShop environments, that leaves you with two legitimate, modern options: Accept Hosted and Accept.js. Both keep credit card numbers off your PrestaShop database, but they handle user experience, frontend execution, and security responsibilities in fundamentally different ways.
Understanding the Architecture: Accept Hosted vs Accept.js
To make the right architectural decision for your PrestaShop store, you first need to understand how each method interacts with your server and the customer’s browser.
Accept Hosted is Authorize.Net’s turnkey hosted payment solution. When a customer reaches the payment step in PrestaShop, your server requests a single-use form token from Authorize.Net and renders a secure payment form embedded directly inside an iframe (or redirects to a hosted page). The customer enters their sensitive card details directly into Authorize.Net’s secure container. Your PrestaShop server never touches, renders, or even transmits the card data fields.
Accept.js, on the other hand, is a client-side JavaScript tokenization library. You build and style standard HTML input fields directly within your PrestaShop checkout theme. When the customer clicks “Place Order,” an Authorize.Net JavaScript library intercepts the event, collects the card data directly from the DOM, and dispatches it over an encrypted channel to Authorize.Net. The gateway returns an opaque payment nonce (a temporary cryptographic token, accompanied by a descriptor). Your module then submits this token back to your PrestaShop controller, which finalizes the transaction through the backend API.
Here is a quick breakdown of how they compare from an architectural perspective:
- Accept Hosted: Authorize.Net renders and controls the payment form elements inside an iframe; communication happens entirely inside their hosted sandbox.
- Accept.js: Your PrestaShop theme renders the input fields; client-side JS captures and exchanges card data for a secure nonce before submitting the form.
- Legacy Methods (DPM/AIM): Deprecated; direct handling or simple form posting that poses significant compliance risks today.
PCI Compliance: SAQ A vs SAQ A-EP
Compliance is the single biggest factor governing this decision. If you accept card payments online, your store must comply with the Payment Card Industry Data Security Standard (PCI DSS). The integration type you choose dictates your compliance tier.
With Accept Hosted, your store generally qualifies for PCI DSS SAQ A. This is the shortest, least demanding compliance level available to e-commerce merchants. Because the card form is rendered entirely within an iframe hosted on Authorize.Net’s infrastructure, your PrestaShop server is completely excluded from the cardholder data environment (CDE). For small-to-midsize merchants without dedicated DevSecOps teams, SAQ A provides peace of mind and significantly lower annual compliance costs.
With Accept.js, your store falls under PCI DSS SAQ A-EP. Why? Even though raw card numbers are tokenized in the browser before hitting your server, the checkout page itself is hosted on your PrestaShop server. If an attacker compromises your server, your theme files, or a third-party analytics script running on the checkout page, they could theoretically alter the JavaScript to skim card details before Accept.js tokenizes them. As a result, SAQ A-EP requires quarterly external ASV (Approved Scanning Vendor) vulnerability scans, rigorous server hardening, strict Content Security Policies (CSP), and automated file integrity monitoring.
Checkout User Experience and PrestaShop 8 Compatibility
While Accept Hosted wins on PCI simplicity, Accept.js is the undisputed winner for native user experience.
When you use Accept.js, the payment fields are native HTML elements inside your PrestaShop theme. They automatically inherit your CSS styling, font hierarchy, input padding, and validation behaviors. If you run a custom one-page checkout module like The Checkout or SuperCheckout, Accept.js sits cleanly inside the layout without layout shifts, scrollbars, or styling disconnects.
Accept Hosted can be embedded inside an iframe on the PrestaShop payment step, but styling it is notoriously finicky. Authorize.Net allows basic parameter styling (custom header colors, button colors, fonts), but you cannot fully match a tailored, bespoke checkout UI. Furthermore, responsive mobile behavior inside an iframe requires dynamic height-resizing scripts using postMessage listeners. If those fail, mobile shoppers end up with double scrollbars or truncated “Pay” buttons, causing cart abandonment.
If you’re building custom payment modules or upgrading your store’s architecture, leveraging tailored PrestaShop payment module services ensures your integration remains resilient across core theme updates and third-party checkout modules.
Real-World Technical Traps in PrestaShop Implementations
Over the course of developing and debugging custom Authorize.Net modules for PrestaShop 1.7 and 8, I have seen developers repeatedly stumble into specific implementation pitfalls.
The AJAX Re-render Trap with Accept.js
One critical lesson I’ve learned from auditing broken PrestaShop checkouts involves core JavaScript events. Modern PrestaShop checkouts dynamically refresh the payment options container via AJAX whenever a user changes their shipping method, applies a voucher code, or toggles an address. If your module binds the Accept.js tokenization trigger using a standard jQuery $('#payment-form').submit(...) listener on document ready, that binding is instantly destroyed as soon as the DOM updates.
To avoid silent checkout submission failures, your module must use event delegation or listen explicitly to PrestaShop’s core event emitters:
// Correct way: Listen to PrestaShop checkout updates
prestashop.on('updatedDeliveryForm', function() {
// Re-initialize or verify Accept.js handlers
});
$(document).on('click', '#payment-confirmation button', function(e) {
// Intercept payment submission reliably
});
Webhook Synchronization vs. hookPaymentReturn
Another common mistake in Authorize.Net implementations is relying solely on the browser redirect (the front controller callback) to create and validate orders. If a customer closes their browser tab immediately after the transaction clears on Authorize.Net’s servers, your PrestaShop store will never record the order, leaving you with an orphaned charge and an unfulfilled customer.
Both Accept Hosted and Accept.js implementations must be paired with Authorize.Net Webhooks (specifically net.authorize.payment.authcapture.created). Your module must listen for this webhook asynchronously, match the transaction ID to the pending PrestaShop cart, and safely validate the order via the PaymentModule::validateOrder() core method if the front-end redirect fails to fire.
Which One Should You Choose for Your Store?
Neither solution is universally superior; your choice depends on your compliance appetite and UX requirements.
Choose Accept Hosted if:
- Your organization requires strict SAQ A PCI compliance to minimize audit expenses and administrative overhead.
- You run a standard PrestaShop classic-based checkout and don’t require heavy aesthetic customization of the card fields.
- You want Authorize.Net to handle all localized card input formatting, 3D Secure challenges, and device fraud profiling within their sandbox.
Choose Accept.js if:
- You run a high-volume store where conversion rate optimization (CRO) and a frictionless, brand-consistent one-page checkout are critical.
- Your technical team is equipped to maintain SAQ A-EP compliance, manage Content Security Policies, and run quarterly vulnerability scans.
- You need complete control over inline error messaging (e.g., dynamically highlighting an expired card date without reloading an iframe).
If you’re unsure which integration fits your operational model or you need a bulletproof Authorize.Net module built from the ground up, with over 10+ years of dedicated experience and 200+ completed projects, I can help you evaluate your architecture. Feel free to get expert help on your custom payment development.
Frequently Asked Questions
Does Accept.js store credit card data on my PrestaShop server?
No, Accept.js sends raw credit card details directly from the customer’s browser to Authorize.Net’s servers. Your PrestaShop database only receives and stores an opaque payment token (nonce), meaning credit card numbers never touch your hosting infrastructure.
Can I style the Accept Hosted payment form to look like my custom PrestaShop theme?
You can configure basic styling options such as primary colors, button styles, and fonts via the Authorize.Net API parameters, but you cannot inject custom CSS or completely override the layout. The form is hosted inside an Authorize.Net iframe, restricting deep visual customization.
Why does my Accept.js module stop working when customers change shipping methods?
PrestaShop’s checkout dynamically updates the payment step via AJAX when shipping methods change, which destroys standard JavaScript event listeners bound to payment inputs. Your module must use event delegation or hook into PrestaShop’s updatedDeliveryForm JavaScript event to maintain tokenization handlers.
