SellAbroad Docs

Troubleshooting

Common integration problems mapped to their cause and fix — rejected carts, missing tax lines, signature failures, stuck payouts, and more.

Most integration problems fall into a handful of buckets. Find your symptom below.

Setup and activation

Buyers can't check out / "Checkout is not activated for this store yet"

What you see: buyers can't create a cart. On WooCommerce the widget shows "Checkout is not activated for this store yet. The store owner needs to finish activating it with SellAbroad."

Cause: your store is registered, but checkout has not been switched on for it.

Fix: In the WooCommerce plugin, open Setup Actions → Register store and run it again — registration activates checkout. Confirm the message says "Checkout is active." If it still reports not active, contact SellAbroad support before going live. On a custom or Shopify integration, ask your account manager to confirm your store is activated.

"Register store" reports that checkout did not activate

What you see: "Checkout is NOT active yet: buyers will see an error at checkout. Click 'Register store' again, or contact SellAbroad support before going live."

Fix: Click Register store again. If it tells you a shared secret already exists from a previous integration, click Reset secret to mint a fresh one — note this stops any older integration on the store from working. Still stuck? Contact SellAbroad support.

"Pay with Credit/Debit" is missing on the WooCommerce checkout

What you see: no SellAbroad payment option, or "no payment method available."

Fix — check in order:

  1. Turn on the master switch: General tab → Enable SellAbroad on this store.
  2. Enable Payment Container under WooCommerce → Settings → Payments.
  3. Confirm the store is registered (Setup Actions → Register store, then Test connection).
  4. On very old WooCommerce without block-payment support, switch your Checkout page to the classic [woocommerce_checkout] shortcode.

Hosted Checkout quietly falls back to the normal WooCommerce checkout

What you see: buyers reach your native WooCommerce checkout instead of the SellAbroad checkout, with no error shown. This is deliberate — the handover fails safe so buyers can always pay — which makes it easy to miss.

Fix: On the Setup Actions tab, run Test handover. It checks, in order: Hosted Checkout mode is selected, the store is registered, a WooCommerce cart token can be issued (a security plugin, WAF, or CDN blocking /wp-json shows up here), and the payment service accepts the cart. Act on the first failing step.

Payments

"Billing details incomplete"

What you see: the charge is rejected with 400"Billing details incomplete."

Cause: a card charge needs the buyer's first name, email, street, city, and country, and not all were present. The usual reason is that field names differ between cart-create and charge, and unknown keys are silently dropped — so a mis-named address looks accepted at cart-create and only fails at payment.

Fix: use the exact field names for each endpoint:

FieldPOST /carts/from-apiPOST /payments/charge (billing)
First nameshipping_address.first_namefirst_name
Emailtop-level emailemail
Streetshipping_address.address_1address_line_1
Cityshipping_address.citycity
State / provinceshipping_address.provincestate
Countryshipping_address.country_codecountry

Last name, address line 2, state/province, postal code, and phone are optional. City or postal code alone is not enough.

A payment "failed" but I got no error

What you see: POST /payments/charge returns 200, but the payment didn't go through.

Cause: card declines (hard, soft, or pending) are not HTTP errors — they come back as 200 with a status field and a customer_message. Only validation or configuration problems are non-2xx.

Fix: branch on the response status and show the customer_message to the buyer. Don't treat 200 as "paid."

Tax

Tax is charged but there is no Tax line

What you see: the WooCommerce order total includes tax, but no separate "Tax" line at checkout, on the confirmation, or in emails.

Cause: on plugin versions before 1.2.2, the SellAbroad tax line only showed when WooCommerce's own tax calculation was enabled.

Fix: update the plugin to 1.2.2 or later (it renders its own Tax line even when WooCommerce taxes are off), or enable WooCommerce → Settings → General → Enable taxes. Stores configured to use their own WooCommerce tax are unaffected.

Webhooks and callbacks (custom API)

Signature verification fails (401)

What you see: our calls to your endpoints — or your calls to us — are rejected with 401.

Fix — the four usual causes:

  • Sign the raw body. Compute the HMAC over the raw, unparsed request bytes. A proxy or framework that re-serializes the JSON changes the bytes and breaks the signature.
  • Use the current shared_secret. If it was rotated (or you ran Reset secret), update both sides.
  • Match the format. The signature is sha256=<hex>, HMAC-SHA256, compared in constant time.
  • Check the clock. We reject an X-Timestamp skew greater than 5 minutes — keep your server on NTP.

Fulfillment and payouts

An order is Completed but the payout is stuck

What you see: you marked the order shipped / Completed, but it never becomes eligible for payout.

Cause: the fulfillment sync fires on the order's status change. If it can't find a tracking number (in order meta or notes) at that moment, it defers — and it does not re-fire when you add tracking afterwards. The order then waits for the next daily reconciliation.

Fix: on WooCommerce, add the tracking number before you mark the order Completed. If you already completed it without tracking, trigger a fresh status change after adding the tracking number, or wait for the next daily reconcile. Local-pickup orders are exempt (no tracking needed) when local-pickup payouts are enabled for your account. See Getting paid.

Carts

Duplicate carts

What you see: two carts created for one checkout.

Cause: creating the cart on your server and letting the embedded widget create it from data-from-api-payload.

Fix: pick one mode (see Custom store). If both paths must run, send the same external_cart_id on each — we key cart creation on your merchant id plus external_cart_id and collapse them into a single cart.

Wallets

Apple Pay won't verify

What you see: enabling Apple Pay reports that the verification file can't be reached.

Fix: serve the exact file at exactly https://yourstore.com/.well-known/apple-developer-merchantid-domain-association, over HTTPS, with no redirect that changes or drops the path, no login in front of it, and the exact filename and casing. Shopify can't host /.well-known/ directly — use the Cloudflare Worker approach in the Apple Pay guide. Then re-run Verify & enable.

On this page