If you run a WooCommerce store that sells to customers in India, the Digital Personal Data Protection Act, 2023, along with the DPDP Rules notified on 14 November 2025, will reshape how you collect, store, and process every order. The clock is now running. Most operational obligations under the DPDPA for WooCommerce stores become enforceable by 13 May 2027, and the penalties for getting it wrong reach ₹250 crore for a single security failure. That is not a typo.

WooCommerce, in its default state, was never built for India’s privacy regime. It was built for global commerce under WordPress, with bolt-on plugins for GDPR. The DPDPA borrows from GDPR in spirit but breaks from it in critical places: there is no “legitimate interest” basis, no separate sensitive-data category, and no flexibility on cross-border transfers when the government draws a line. For most WooCommerce store owners in India, this means roughly eighteen months of work compressed into whatever budget they can find.

Here’s what actually changes.

What Does DPDPA Mean for a WooCommerce Store?

The DPDPA for WooCommerce stores means every Indian shop running on the platform becomes a “Data Fiduciary” the moment it collects a customer’s name, address, phone number, or email at checkout. A Data Fiduciary, under Section 2(i) of the Act, is any entity that decides why and how personal data gets processed. If you set up the WooCommerce store, you are that entity. The customer, called a Data Principal under the Act, now holds enforceable rights over their data: access, correction, erasure, grievance redressal, and the right to nominate someone to act on their behalf.

That changes the relationship.

Before the rules were notified, a WooCommerce store could collect a phone number for delivery, retain it forever, and resell to a marketing list with no real consequence beyond a policy page nobody read. After May 2027, every step of that flow needs documented, withdrawable, purpose-specific consent. The WooCommerce checkout page, the abandoned-cart email plugin, the Facebook Pixel firing in the footer, the third-party shipping integration that pulls customer data into a SaaS dashboard, all of it becomes a regulated processing activity.

For an in-depth legal walkthrough of how the DPDP Rules operationalize the Act, the IAPP analysis of India’s DPDPA operational impacts is one of the more rigorous public references available, written by Indian privacy practitioners.

Why Default WooCommerce Settings Won’t Pass a DPDPA Audit

WooCommerce ships with privacy controls that were designed for GDPR and never updated for India. That is the core problem. Out-of-the-box, the platform stores customer addresses, billing details, IP logs, and order metadata without any granular consent layer. The “Accounts & Privacy” panel under WooCommerce settings lets you set retention windows for inactive accounts and failed orders, but the defaults are off.

Most stores never touch them.

Here is what the default WooCommerce stack typically gets wrong against the DPDP Rules:

• No itemized notice at the point of collection. Rule 3 requires a clear, standalone privacy notice listing every category of personal data processed, the specific purpose for each, and a working link to withdraw consent. WooCommerce’s default checkout page links to a generic privacy policy, which does not satisfy the itemization requirement.
• Pre-ticked or bundled consent boxes. Section 6 of the DPDPA mandates that consent be free, specific, informed, unconditional, and unambiguous. A single “I agree to the terms and privacy policy” checkbox at checkout, used by most WooCommerce themes, fails on three of those five criteria simultaneously.
• No consent withdrawal flow. Customers must be able to withdraw consent as easily as they gave it. Most WooCommerce stores have no mechanism for this beyond a “contact us” email.
• Cookies fired before consent. The Facebook Pixel, Google Analytics, hotjar, abandoned-cart trackers, and remarketing tags on most WooCommerce stores execute on page load. Under the DPDP Rules, non-essential trackers cannot run until the Data Principal opts in.
• Indefinite data retention. The Third Schedule of the DPDP Rules sets a default retention window of three years from last transaction or login for ecommerce entities with two crore or more users. Smaller stores still owe a documented retention policy and an erasure mechanism, both of which are absent in default WooCommerce.

There is more under the surface, particularly in the plugin layer.

Which DPDPA Obligations Hit WooCommerce Hardest?

Three obligations stand out as operational bombs for a typical WooCommerce setup: granular consent, breach notification within 72 hours, and the data principal rights workflow. Each one breaks something that most stores currently rely on.

Consent at the cookie and form layer. A WooCommerce store usually runs ten to twenty third-party scripts, including analytics, ad pixels, chat widgets, review platforms, and shipping integrations. Under DPDPA, every one of those scripts that touches personal data needs an opt-in before it fires. That is not a checkbox plugin. It is a tag-management overhaul, often involving Google Tag Manager, a registered Consent Manager once the framework matures in late 2026, and surgical edits to theme files. The IAB-style cookie consent banners many stores already use were built for GDPR and TCF v2.3, not DPDPA’s notice-and-consent model. They need reconfiguration, not just installation.

Breach notification in 72 hours, with a preliminary notice “without delay.” Rule 7 of the DPDP Rules creates a dual-clock obligation. The Data Protection Board of India must be intimated immediately upon discovery of any breach, with a detailed report filed within 72 hours covering the nature, extent, location, cause, impact, and remedial steps. Affected customers must also be notified directly. For a small WooCommerce store running on shared hosting with no SIEM, no log retention discipline, and no incident response runbook, meeting that deadline is genuinely difficult, and missing it carries a penalty reaching ₹200 crore. Most owners simply have not budgeted for forensic readiness.

Data Principal rights fulfillment within 90 days. Customers can ask for their data, ask for corrections, ask for erasure, or file grievances. Rule 14 sets a 90-day grievance resolution window. WooCommerce has a built-in personal data export and erasure tool under Settings > Accounts & Privacy. That is a start. It does not, however, capture data sitting in third-party integrations: Mailchimp, Zoho, Razorpay, Shiprocket, the WhatsApp Business API. Each of those needs its own Data Processing Agreement under Rule 6(f).

There is one more thing.

If your store processes children’s data in any form, including parental purchases of school supplies or kids’ toys, Rule 10 imposes verifiable parental consent through DigiLocker or an approved identity wallet. Behavioral profiling and targeted advertising directed at children are flatly prohibited.

How Should WooCommerce Owners Prepare for DPDPA Before May 2027?

Start with a data map. You cannot protect what you cannot see, and most WooCommerce store owners have no inventory of where customer data actually lives. Order tables in MySQL, yes, but also: backup files on Dropbox, exported CSVs sitting in someone’s Gmail, the abandoned-cart database in Klaviyo, the loyalty app’s customer list, the WhatsApp broadcast group with 4,000 phone numbers. All of it is regulated personal data. All of it needs a documented purpose, a retention window, and a deletion mechanism.

After the data map, sequence the work in roughly four phases:

1. Gap assessment and policy redrafting (now through Q2 2026). Audit every plugin, integration, and form for what data is collected and why. Rewrite the privacy notice into an itemized, plain-language document that maps each data category to a specific purpose. Update Terms & Conditions, the cookie policy, and the refund/returns flow to reference DPDPA-aligned consent.
2. Technical implementation (Q2 2026 through Q1 2027). Replace the legacy cookie banner with a DPDPA-aware Consent Management Platform. Reconfigure Google Tag Manager so non-essential tags fire only after opt-in. Add granular consent checkboxes at checkout for marketing, analytics, and third-party sharing. Build an erasure pipeline that wipes data across primary and third-party systems.
3. Security hardening and breach readiness (parallel track). Encrypt data at rest using AES-256, enforce TLS 1.3 in transit, lock down WordPress admin with MFA and role-based access, and retain access logs for the one-year minimum mandated by Rule 6. Write an incident response runbook with named owners, contact templates for the DPB, and a 72-hour reporting timeline tested through tabletop drills.
4. Vendor governance and final audit (Q1 to Q2 2027). Sign DPDPA-compliant Data Processing Agreements with every vendor that touches Indian customer data, from your hosting provider to your shipping aggregator. Conduct a final compliance audit, ideally with an external assessor, before the 13 May 2027 deadline.

Eighteen months sounds like a lot. It is not. If you are currently running ten plugins, five marketing integrations, and a custom checkout flow, the consent layer alone will eat three to six months of focused work. Stores that wait until Q4 2026 to start are going to scramble.

If your team needs structured help, our DPDPA implementation services for WooCommerce stores cover the full sequence from gap assessment to vendor DPAs.

What Are the Penalties for a Non-Compliant WooCommerce Store?

The Schedule to the DPDPA caps penalties at ₹250 crore for failure to implement reasonable security safeguards under Section 8(5). Failure to notify a breach to the Board or to affected customers carries up to ₹200 crore under Section 8(6). Mishandling children’s data, up to ₹200 crore. Non-compliance with Significant Data Fiduciary obligations, ₹150 crore.

Will a small WooCommerce store actually face ₹250 crore? Probably not. The Data Protection Board considers the nature, gravity, and duration of the breach, the type of data affected, repetitive conduct, monetary gain realized, and the effectiveness of mitigation when sizing the penalty. A first-time, low-impact breach by a small store with documented good-faith compliance will likely draw a fraction of the cap. But “fraction of ₹250 crore” still ruins most ecommerce businesses in India.

The reputational cost is worse. A breach notification published on the DPB’s website, with your store named, will sit in Google search results indefinitely. Customer trust on a WooCommerce store, particularly in fashion, beauty, jewellery, and D2C electronics, runs on a thinner margin than most owners realize. One public breach, one regulatory order, and conversion rates collapse.

Where Most WooCommerce Stores Get DPDPA Compliance Wrong

In our work assessing WooCommerce stores for DPDPA readiness, we keep seeing the same five mistakes:

The first is treating it as a plugin problem. It is not. Compliance is a process, governance, and contractual exercise. No plugin alone makes a store DPDPA compliant, regardless of what its marketing page says. The WebToffee, CookieYes, and Real Cookie Banner plugins help. They cover one slice. The remaining ninety percent sits in policies, vendor contracts, data flows, and incident response.

The second is assuming the May 2027 deadline gives breathing room. Boards and customers will not wait that long. Class-action style consumer complaints to the DPB are already possible under the immediately-effective provisions. Procurement departments at larger Indian buyers are starting to demand DPDPA attestations from their D2C suppliers as a vendor onboarding requirement, and that pressure scales upward through the supply chain.

The third is forgetting about backups. Backup files containing personal data fall fully within the scope of the Act. A retention policy that erases data from the live database but leaves the same data in a six-month-old backup creates exposure on every audit.

The fourth, and the one that surprises most store owners, is the WhatsApp problem. If you run customer support, order updates, or marketing through WhatsApp Business API, every contact is regulated personal data, every broadcast needs documented consent, and every integration partner needs a DPA. Most stores have none of this.

The fifth is the children’s-data blind spot. Stores selling kids’ clothing, toys, school supplies, baby products, or anything where the buyer is purchasing on behalf of a minor need verifiable parental consent flows. DigiLocker integration is non-trivial. Skipping it because “the parent is the buyer” is not a defensible legal position.

Compliance is a build year, not a checkbox. The stores that start now and treat DPDPA for WooCommerce as a customer-trust investment rather than a regulatory cost will come out of 2027 in a stronger position than competitors who delayed.

If you need a structured assessment of where your WooCommerce store stands against DPDPA today, with a phased roadmap to the 13 May 2027 deadline, book a DPDPA gap assessment with our team. We have walked Indian D2C and B2B stores through privacy frameworks before, and the work is more manageable when sequenced correctly from the start.

This documentation explains how card transactions move through WooCommerce and Authorize.Net, and how to decide between capture, void, and refund. It also reflects capabilities commonly used with the Indatos Datamatix Authorize.Net WooCommerce gateway plugin, including authorize-only, capture later, refunds/voids from the order screen, and WooCommerce Blocks checkout support.

Product reference: Authorize.Net WooCommerce Plugin

1) TL;DR (READ THIS FIRST)

• Customer places order → Authorize.Net returns an approval, decline, or error response.
• Approved payments can be Auth+Capture (sale) or Auth-only (funds held).
• Captured transactions still require settlement (batch) before funds are finalized.
• Before settlement: use void. After settlement: use refund.
• This plugin supports: authorize-only, manual capture, partial refunds, and WooCommerce Blocks checkout.

2) QUICK GLOSSARY (PLAIN ENGLISH)

• Authorization (Auth): Funds are approved and held, but not yet collected.
• Capture: You collect the authorized funds (turns a hold into a charge).
• Settlement: Authorize.Net batches captured transactions for processing.
• Void: Cancels an authorized or captured transaction before it settles.
• Refund: Returns money after a transaction has settled.
• Auth-only mode: Authorize first, capture later (manual or workflow-based).
• Auth+Capture (Sale): Authorize and capture immediately.

3) THE LIFECYCLE OF AUTHORIZE.NET TRANSACTION (ONE SIMPLE FLOW)

Checkout flow

Checkout
  → Approved?
     → NO: Declined/Error → WooCommerce shows failed/pending → troubleshoot/logs
     → YES:
         → Mode = Auth+Capture (Sale)
              → Captured
              → Settlement (batch)
              → Completed
              → If needed: Refund (after settlement)
         → Mode = Auth-only
              → Authorized (funds held)
              → Manual Capture (when you choose)
              → Settlement (batch)
              → Completed
              → If needed: Refund (after settlement)

Side paths:
- Void is available before settlement (authorization or capture can often be voided pre-settlement).
- Refund is used after settlement.

4) STEP-BY-STEP: WHAT HAPPENS WHEN CUSTOMER CLICKS “PLACE ORDER”

4.1 Payment initiated

• Customer enters card details at checkout (Blocks checkout can be supported, depending on your setup).
• WooCommerce creates the order and sends the payment request to Authorize.Net.
• Authorize.Net returns one of three outcomes: approved, declined, or error.

4.2 Response outcomes (what it means)

4.3 Mode matters: Auth+Capture vs Auth-only

A) Auth+Capture (Sale)

• Funds are captured immediately (customer is charged).
• Settlement happens later during Authorize.Net batch processing.
• Use refund after settlement if you need to return money.

B) Auth-only

• Funds are authorized and held.
• You decide when to capture.
• Useful for manual review, backorders, high-risk orders, address verification, or phone verification workflows.

5) MANUAL CAPTURE (AUTH-ONLY WORKFLOW)

5.1 When to use manual capture

• You want to verify stock, address quality, fraud signals, or customer details before charging.
• You fulfill later and want to capture closer to shipment date.
• You need a review step for high-value carts.

5.2 How manual capture works (high-level)

• Order is placed → status is commonly On-hold or similar (your store settings can change this).
• Admin reviews the order.
• Admin triggers capture from the WooCommerce order screen (manual capture supported).
• After capture, the transaction moves toward settlement.

5.3 Common capture mistakes

• Waiting too long (authorization holds can expire based on merchant settings).
• Attempting refund when you actually need void (pre-settlement).
• Capturing twice due to duplicate actions or plugin conflicts.

6) SETTLEMENT (WHY VOID VS REFUND CONFUSES PEOPLE)

6.1 Captured does not mean settled

• Capture is the action that creates a charge.
• Settlement is when the gateway batches transactions for processing.
• A transaction can be captured but not yet settled for a period of time.

6.2 The rule you should memorize

7) VOID VS REFUND (DECISION TREE + EXAMPLES)

7.1 Decision tree

Question: Has the transaction settled?

• No → void (fastest way to cancel; typically no money moves to the customer bank)
• Yes → refund (money is returned after settlement)

7.2 Real examples

• Customer cancels within minutes → void (often pre-settlement)
• Customer cancels next day → refund (often settled)
• You shipped the wrong item → partial refund (supported)

8) PARTIAL REFUNDS (SUPPORTED)

8.1 When to use partial refunds

• Item returned but shipping fee is kept
• One item out of multiple is refunded
• Price adjustment after purchase

8.2 How partial refunds work (conceptually)

• You choose a refund amount in WooCommerce.
• The plugin sends a refund request to Authorize.Net for that amount.
• The refund is tied to the original settled transaction.

8.3 Partial refund notes

• Multiple partial refunds may be possible depending on gateway and account settings.
• If the transaction is not settled yet, void is usually the correct action (refund can fail pre-settlement).

9) STATUS MAPPING: WOOCOMMERCE AUTHORIZE.NET (ADD TABLE)

Status mapping table template

This mapping can vary by store settings, plugin configuration, and your fulfillment rules. Use the table below as a starting template and adjust to match your setup.

10) BLOCKS CHECKOUT NOTES (SUPPORTED)

Blocks checkout support and display issues

• This plugin supports WooCommerce Blocks checkout.
• If checkout does not display the gateway, confirm the gateway is enabled in WooCommerce payments.
• Confirm you are using Blocks checkout (not classic checkout) if your site theme uses Blocks.
• Check for caching/minification conflicts and retest.
• Test with a default theme and temporarily disable conflicting plugins.
• Check plugin logs for gateway initialization errors.

11) TROUBLESHOOTING (SHORT + LINKS TO DEEPER DOCS)

11.1 Refund failed

Common causes:

• Transaction not settled yet (void is required instead of refund)
• Wrong keys, permissions, or mode mismatch
• Transaction ID mismatch
• Temporary gateway/API issue

11.2 Payment declined

• Bank decline, AVS/CVV mismatch, fraud filters, insufficient funds
• Try a different card and review fraud rules in the Authorize.Net dashboard

11.3 Duplicate charges

• Double click, refresh/back button behavior, or repeated checkout submission
• JavaScript issues caused by caching/minification
• Theme/plugin conflicts or multiple gateways interacting

Helpful links

• Indatos Authorize.Net insights and guides
• Authorize.Net error e00027 troubleshooting
• API keys explained (Login ID vs Transaction Key)

12) BEST-PRACTICE SETTINGS (RECOMMENDED DEFAULTS)

Recommended defaults

• For most stores: Auth+Capture (simpler operations)
• Use Auth-only when: manual review, high-risk orders, delayed fulfillment
• Enable logs only when troubleshooting; disable when stable
• Always test in sandbox before going live

13) FAQ (USE THIS FOR FAQ SCHEMA)

When does the money hit my bank?

Typically after capture and settlement, funds move through the payment network to your bank on a schedule defined by your merchant account and bank processing timelines. Settlement is the key point that separates void vs refund decisions.

Why can’t I void this transaction?

Voids generally apply before settlement. If the transaction has already settled, you usually must refund instead.

Why did my refund fail?

The most common reason is that the transaction has not settled yet. In that case, void is usually the correct action. Other reasons include configuration issues, key/mode mismatch, or gateway-side limitations.

Can I do partial refunds?

Yes. Partial refunds are supported. You select an amount in WooCommerce and submit the refund to Authorize.Net for that amount.

Can I authorize only and capture later?

Yes. Authorize-only (capture later) is supported. This is useful for manual review workflows or delayed fulfillment.

Does it work with WooCommerce Blocks?

Yes. Blocks checkout is supported. If the gateway does not appear, review the Blocks troubleshooting section and check for caching or plugin conflicts.

Where do I find transaction logs?

Log locations depend on your site configuration and plugin settings. Check the plugin’s logging option in the gateway settings, and review WooCommerce logs in the WordPress admin if enabled.

Recommended next actions

• Install and setup: Installation and setup guide
• Troubleshooting deep dive: Error codes and e00027 troubleshooting
• Product page and licenses: Authorize.Net WooCommerce plugin
• Contact support: Support and contact

What to include when contacting support

• Order ID and transaction ID (if available)
• Time of the attempt and your store timezone
• Whether the transaction was auth-only or sale
• Whether the gateway was in sandbox or production mode
• Relevant log excerpts (remove cardholder data)

Neha Jain is a software engineer focused on payments and API-driven integrations, including webhooks, authentication, error handling, and secure deployment patterns. Her work emphasizes production-ready implementations, with attention to vendor specifications, common failure modes, and integration reliability. She brings a practical approach to system design, balancing performance, security, and maintainability. Neha’s focus is on helping teams implement complex technical workflows with clarity and fewer regressions.

This guide explains how to test credit card payments using an Authorize.Net sandbox account in a WooCommerce store using the Indatos Datamatix Authorize.Net gateway plugin. Sandbox testing helps you validate checkout, payment approval/decline behavior, and order updates without processing real money.

Product reference: Authorize.Net WooCommerce Plugin

What you will accomplish

• Create an Authorize.Net sandbox account
• Generate sandbox API credentials (API Login ID and Transaction Key)
• Configure the plugin for sandbox mode in WooCommerce
• Run end-to-end checkout tests with sandbox test cards
• Verify transactions in WooCommerce and in the Authorize.Net sandbox dashboard

Prerequisites

• WordPress admin access to your store
• WooCommerce installed and active
• Indatos Authorize.Net plugin installed and active
• Your plugin license key (if your build requires license activation)
• A staging site is recommended for testing. Testing on live sites is possible, but you must keep sandbox mode enabled and use sandbox credentials.

Key concepts you should understand

• Sandbox and production are separate environments. Sandbox credentials do not work in production, and production credentials do not work in sandbox.
• The plugin has a mode toggle (sandbox/test vs production/live). The mode must match the type of keys you paste into the settings.
• If the mode and keys do not match, you will typically see authentication errors such as “incorrect authentication values” or “authentication failed.”

Step 1: Create an Authorize.Net sandbox account

Authorize.Net sandbox accounts are created through the Authorize.Net Developer portal. Use the sandbox signup link below and follow the registration flow.

• Open the sandbox signup page: Authorize.Net Sandbox signup
• Create your developer account (email, password, and basic profile details)
• After signup, you will have access to the sandbox environment at: sandbox.authorize.net

Tip: Keep the sandbox login credentials saved securely. You will need them whenever you generate or rotate keys, review test transactions, or change sandbox configuration.

Step 2: Generate sandbox API credentials (API Login ID and Transaction Key)

The plugin typically requires two credentials from your Authorize.Net sandbox merchant interface:

• API Login ID
• Transaction Key

To generate these credentials in the sandbox merchant interface:

• Sign in to the sandbox merchant interface: sandbox.authorize.net
• Go to Account
• Under Security Settings, open API Credentials and Keys
• Copy the API Login ID
• Generate a new Transaction Key and copy it immediately

Important handling notes:

• The Transaction Key is sensitive. Store it in a secure password vault or secrets manager.
• If you rotate keys later, you must update the plugin settings with the new Transaction Key.
• Do not paste keys into public tickets, screenshots, or shared documents.

Step 3: Configure the Indatos plugin for sandbox testing

After you have sandbox credentials, configure the gateway in WooCommerce.

Open the plugin settings using either path below:

• WooCommerce → Settings → Payments → Authorize.Net → Manage
• Plugins → Installed Plugins → locate the Authorize.Net plugin → Settings

In the gateway settings:

• Paste your plugin license key (if the plugin shows a license field)
• Set the mode to Sandbox or Test mode (wording varies by build)
• Enter the sandbox API Login ID
• Enter the sandbox Transaction Key
• Save changes

Quick validation checklist after saving:

• The gateway shows as enabled in WooCommerce payments
• The checkout page displays the Authorize.Net payment option
• No authentication error appears in the plugin status/log area (if available)

Step 4: Run checkout testing (end-to-end)

Prepare your store for a clean test

• Create a simple product with a small price (for example 1.00)
• Ensure shipping and taxes are not blocking checkout (you can test with a virtual product to avoid shipping)
• If your checkout uses blocks, keep it enabled. The Indatos plugin supports block checkout and classic checkout.

Use sandbox test card numbers

Authorize.Net publishes test cards that work only in the sandbox. Use any future expiration date. Use any 3-digit CVV for most cards.

• Visa: 4111111111111111
• Visa: 4012888818888
• Mastercard: 5424000000000015
• American Express: 370000000000002 (use a 4-digit CVV)

Source: Authorize.Net Testing Guide

Place a test order

• Add the test product to cart
• Proceed to checkout
• Select the Authorize.Net payment method
• Enter a sandbox test card number, expiration date, and CVV
• Place the order

Verify results in WooCommerce

• Go to WooCommerce → Orders
• Open the test order
• Confirm the order status is updated appropriately (processing/completed/on-hold depends on your store settings)
• Look for transaction information (authorization code, transaction ID, notes) if the plugin displays it on the order screen

Verify results in the Authorize.Net sandbox dashboard

• Sign in to the sandbox merchant interface: sandbox.authorize.net
• Locate your transactions list or reporting area
• Confirm the test transaction appears with the expected amount and status

Optional tests: refund and void

Your plugin build supports refunds and voids from WooCommerce:

• Open the order in WooCommerce
• Initiate a refund or void (depending on settlement state)
• Confirm the action reflects in WooCommerce order notes and in the sandbox transaction history

Step 5: Troubleshooting common sandbox issues

Authentication failed or incorrect authentication values

• Confirm the plugin is in Sandbox/Test mode
• Confirm you used sandbox API Login ID and sandbox Transaction Key, not production keys
• Re-copy and paste credentials to remove hidden spaces
• If you recently generated a new Transaction Key, update the plugin with the newest key

Authorize.Net method does not show at checkout

• Ensure the gateway is enabled in WooCommerce → Settings → Payments
• Confirm you saved settings after entering keys
• Check that your currency and store country settings are supported by your payment configuration
• If using a caching plugin, clear cache and test again

Checkout errors only on blocks or only on classic checkout

• Confirm your WooCommerce checkout mode (block checkout vs classic)
• Update WooCommerce and the gateway plugin to the latest compatible versions
• Temporarily switch to a default theme to rule out theme conflicts

Step 6: Sandbox testing checklist

Before testing

• Sandbox account created
• Sandbox API Login ID and Transaction Key generated
• Plugin set to Sandbox/Test mode
• Sandbox keys pasted and saved in plugin settings
• Gateway enabled and visible at checkout

During testing

• At least one successful payment attempt with sandbox test card
• Order created correctly in WooCommerce
• Transaction appears in Authorize.Net sandbox dashboard

After testing

• Optional refund or void tested (if your workflow requires it)
• Store logs reviewed for warnings/errors
• Notes recorded for go-live configuration

Step 7: Next steps (moving from sandbox to live)

When you are ready to accept real payments:

• Switch the plugin mode to Production/Live
• Replace sandbox keys with production API Login ID and production Transaction Key
• Run a small real transaction to confirm live processing
• Continue monitoring payments and keep the plugin updated

FAQ

Do sandbox transactions charge real money?

No. Sandbox transactions never reach financial institutions. They are test-only and do not move real funds.

Can I use my production API Login ID and Transaction Key in sandbox?

No. Sandbox and production are separate environments and require separate credentials. Mixing them causes authentication failures.

Where do I find the API Login ID and Transaction Key in sandbox?

Sign in to the sandbox merchant interface at sandbox.authorize.net, then go to Account, open Security Settings, and choose API Credentials and Keys.

What does “incorrect authentication values” mean?

It usually means the plugin mode does not match the credentials you entered, or the API Login ID and Transaction Key were copied incorrectly. Confirm sandbox mode is enabled and re-paste your sandbox keys.

What test card should I use?

Use Authorize.Net’s published sandbox test cards, such as 4111111111111111 for Visa. Full lists and rules are available in the Authorize.Net testing guide: developer.authorize.net testing guide.

Can I test on my live website?

Yes, but it is safer to test on a staging site. If you must test on a live site, ensure the plugin remains in Sandbox/Test mode and that sandbox keys are in place, so real payments are not processed.

Does the Indatos plugin support checkout blocks?

Yes. The Indatos Authorize.Net WooCommerce plugin supports both block checkout and classic checkout. Refer to the product page for current compatibility details: Authorize.Net WooCommerce plugin.

SSL is one of those things most store owners only notice when something breaks. A checkout fails, a customer sees a “Not Secure” warning,
or a payment method stops working after a theme or plugin update. In reality, SSL is not a “nice to have” for ecommerce. It is foundational.
If you accept payments in WooCommerce, SSL is the baseline that protects customers, prevents avoidable technical failures, and keeps your
checkout experience stable across modern browsers.

 What is SSL (and what does HTTPS actually mean)?

“SSL” is the common shorthand people use for website encryption. Technically, modern websites use TLS (Transport Layer Security), but in
everyday ecommerce conversations, “SSL” usually means: My site loads over HTTPS and the browser shows a lock icon.

When your site uses HTTPS:

• The data sent between a customer’s browser and your server is encrypted in transit.
• The customer’s browser can verify that it is talking to your real domain, not an impersonator.
• Modern browsers treat your pages as a secure context, which matters for many payment and authentication flows.

For WooCommerce, this applies to more than credit card fields. A typical checkout page includes customer names, addresses, email, phone,
order totals, and session identifiers. Even if your gateway uses tokenization and card details never hit your server, your checkout still
carries sensitive customer and order data that should be protected.

Why SSL matters for ecommerce and WooCommerce

1) It protects customer data in transit

On an HTTP site (no HTTPS), anyone who can intercept traffic between a customer and your website can potentially see or manipulate the data
being sent. Public Wi-Fi networks, compromised routers, and malicious proxies are real risks.

Ecommerce pages are high value targets. Customer accounts, order details, and checkout requests are exactly the type of data an attacker wants.

2) It builds trust and reduces checkout friction

Browsers actively warn customers when forms are loaded on non-HTTPS pages. If a customer sees “Not Secure” at checkout, even a legitimate
store can look risky. That warning increases drop-off, especially on mobile.

Cart abandonment is already high across ecommerce. Baymard Institute’s research has reported cart abandonment rates around 70% (their figures
vary by study and period, but the takeaway is consistent: checkout is fragile and trust signals matter). You do not want to add a browser
security warning to an already sensitive conversion moment.
External reference

3) It enables modern browser requirements used in payment flows

Many modern web capabilities are restricted to secure contexts (HTTPS). Payment and authentication scripts often assume a secure origin.
Even if some flows work without HTTPS in a controlled scenario, they become unreliable in production conditions because browsers and third-party
scripts increasingly enforce secure-by-default behavior.

4) It is a baseline security control for payment pages

SSL is not the only security requirement for taking payments, and it does not automatically make you compliant with PCI requirements.
But it is a minimum standard. If you are handling ecommerce checkout traffic without HTTPS, you are operating below the baseline security posture
expected by customers, payment providers, and auditors.

5) It supports SEO and long-term site quality

Google has publicly stated that HTTPS is a ranking signal. It is usually not the only factor, but it is a standard expectation for modern sites.
External reference

The problem: what happens when SSL is missing or misconfigured

The failure modes are not limited to “customers see a warning.” A missing or broken SSL setup can create direct payment issues.

1) Browser warnings and user drop-off

If your checkout page is not served over HTTPS, many browsers will show “Not Secure,” especially on pages with form fields.
Customers abandon. Some will not even attempt payment.

2) Payment failures or unstable gateway behavior

Authorize.Net workflows, including client-side tokenization approaches, are designed to operate in secure contexts. Without HTTPS, you may see:

• Tokenization not initializing correctly
• Payment scripts blocked due to security policy
• Intermittent failures that appear after browser updates

3) Mixed content errors that break checkout

Mixed content happens when a page loads over HTTPS but pulls some resources over HTTP, such as scripts, iframes, images, or CSS.
Browsers may block insecure scripts outright, degrade the experience, or show warnings that reduce trust. If a payment-related script is blocked,
your checkout can fail even though the page itself appears secure.

4) Admin and callback issues (webhooks and endpoint validation)

Payment systems increasingly rely on server-to-server callbacks or webhooks to keep order state accurate. If your endpoints are inconsistent
(some HTTP, some HTTPS), or if your site detects its own URLs incorrectly behind a proxy or CDN, you can trigger failed webhook verification,
incorrect return URLs, redirect loops, and inconsistent behavior.

Why Authorize.Net payments in WooCommerce effectively require SSL

Even if your store uses a hosted form or tokenization library, WooCommerce checkout still contains customer identity and address information,
order totals, session identifiers, and payment intent metadata. SSL ensures that the customer’s checkout request cannot be read or modified
in transit. It also ensures that payment scripts can run reliably without being blocked by browser security rules.

In practice, running WooCommerce with Authorize.Net in production without HTTPS usually leads to one of two outcomes:

• You lose conversions due to browser warnings.
• You chase avoidable technical failures caused by insecure context and mixed content.

Where to get an SSL certificate (free and paid options)

Free SSL: Let’s Encrypt

Let’s Encrypt provides free TLS certificates and is widely supported by hosting providers. Many hosts offer one-click SSL provisioning using
Let’s Encrypt, plus automatic renewals. This is often the fastest path to HTTPS for WooCommerce.

You can publish a dedicated Let’s Encrypt setup guide later. For now, the key takeaway is simple:
free SSL is usually available and is often enough for standard ecommerce stores.

Paid SSL providers (3 options)

Paid certificates can be useful if you need enterprise validation options, specific warranty programs, multi-domain complexity, or dedicated support.
Common providers include:

• DigiCert
• Sectigo
• GlobalSign

SSL checklist for WooCommerce (practical setup validation)

• Certificate validity: not expired, correct domain, full chain installed, covers www and non-www if needed.
• Force HTTPS: Cart, Checkout, My Account, and any custom checkout or confirmation pages.
• WordPress URLs: WordPress Address (URL) and Site Address (URL) should both use HTTPS.
• No hardcoded HTTP: theme assets, custom scripts, embedded content, fonts, third-party tags.
• CDN/proxy correctness: ensure HTTPS is detected correctly and redirects do not loop.
• Redirects: HTTP should redirect to HTTPS; enforce one canonical domain version.

How to test SSL installation on your website

You want to test three things: the certificate is valid, the site consistently serves HTTPS, and checkout pages have no mixed content errors.

1) Quick browser tests

• Visit your homepage, cart, checkout, and my account pages.
• Confirm the browser shows a lock icon or “Connection is secure.”
• Review certificate details: issuer, expiry date, and domain coverage.

2) Mixed content test using browser DevTools

• Open your checkout page.
• Open DevTools (Chrome: F12 or Ctrl+Shift+I).
• Check the Console tab for “Mixed Content” warnings and blocked resources.

If you see mixed content, fix it before you troubleshoot payment behavior.
Mixed content can silently block payment scripts.

3) Run an external SSL scan

Use a public SSL testing tool to validate certificate and configuration details. SSL Labs is widely used:
SSL Labs SSL Test

What to check:

• Certificate validity and chain
• Protocol support (modern TLS)
• Redirect behavior (HTTP to HTTPS)
• Warnings about misconfiguration

4) WooCommerce-specific functional test

• Place a test order using a safe testing setup or gateway test mode if available in your environment.
• Confirm checkout stays on HTTPS, no warnings appear, and the order updates correctly.
• Confirm the thank-you page remains on HTTPS.

Common WooCommerce + Authorize.Net issues tied to SSL

Symptom: checkout page shows “Not Secure”

Likely causes include SSL not active on the checkout URL, WordPress site URLs still set to HTTP, or mixed content warnings triggered by
hardcoded HTTP assets.

Symptom: payments fail intermittently, or scripts do not load

Likely causes include mixed content blocking payment scripts, a CDN or proxy not serving HTTPS consistently, or a non-secure context being
served under certain routes.

Symptom: checkout redirects between HTTP and HTTPS

Likely causes include conflicting redirect rules, proxy header issues causing WordPress to mis-detect scheme, or mixed canonical configuration
for www vs non-www.

SSL is not just about a lock icon. It is about running a stable ecommerce checkout that modern browsers trust and payment flows can reliably execute.
For WooCommerce stores accepting Authorize.Net payments, SSL becomes effectively non-negotiable because it protects customer data, prevents
browser-level blocking, reduces checkout friction, and avoids misconfiguration issues that look like gateway problems but are actually HTTPS problems.

If your store is not fully HTTPS today, prioritize it before you spend time debugging payment behavior. Get a certificate (free via Let’s Encrypt
is often enough), force HTTPS across cart and checkout, fix mixed content warnings, and validate your setup with both browser tools and an external
SSL scan. Once HTTPS is stable, everything else in your payments stack becomes easier to test, maintain, and scale.

Further reading

• Let’s Encrypt
• Google: HTTPS as a ranking signal
• Baymard: Cart abandonment research
• SSL Labs: SSL server test

Neha Jain is a software engineer focused on payments and API-driven integrations, including webhooks, authentication, error handling, and secure deployment patterns. Her work emphasizes production-ready implementations, with attention to vendor specifications, common failure modes, and integration reliability. She brings a practical approach to system design, balancing performance, security, and maintainability. Neha’s focus is on helping teams implement complex technical workflows with clarity and fewer regressions.