Ticketing - payment - headless website - invalid redirect

Ask the community
, ,
1

Wix Headless · Support case

Events ticket checkout fails with INVALID_PAYMENT_REDIRECT_URL

No ticket order has ever been created on this site. Every buyer reaches the Wix-hosted ticket form, submits their details, and the place-order call is rejected. The Events API itself works when called directly — only the hosted checkout fails.

What we need: confirmation of how a self-managed headless project should serve Wix-hosted checkout when the site’s primary domain points to an external host, and why paymentRedirectUrl on our connected subdomain is rejected. A second, separate defect is described in §6 (a server-side crash in your URL builder).

1. Account and environment

Item Value
metaSiteId d8c2d5e1-46fb-4feb-ac98-84bf9b799d63
hosted-pages siteId f6e17b70-3e61-4deb-af12-1919a3840ff3
OAuth client 9b14296d-11f5-430e-91ba-356dc060f0f4 (“master”, WEB_APP / REACT)
Frontend www.stylemachine.art — self-managed headless (Next.js on Vercel)
Primary domain stylemachine.art — NAMESERVERS, assignmentType PRIMARY, dnsPropagationStatus FAILED
Wix pages host checkout.stylemachine.art — assignmentType REDIRECT, dnsPropagation COMPLETED
Published primary URL https://www.stylemachine.art/

2. The failure

The buyer selects tickets on our site. We create a reservation, then a redirect session, and send them to the Wix-hosted ticket form. The form loads correctly. They enter first name, last name and email and press Next. The place-order request returns 400:

"grpc-status-details": {
  "applicationError": {
    "code": "INVALID_PAYMENT_REDIRECT_URL",
    "description": ""
  }
},
"failed-client.method": "wix.events.ticketing.CheckoutService/Checkout",
"failed-client.options.authority": "com.wixpress.events.events-ticketing-v1-proxy"

The browser shows only “Some fields have invalid or missing information.” The request payload the hosted page sent:

{
  "data": { "firstName": "...", "lastName": "...", "email": "..." },
  "guests": null,
  "reservationId": "f28ecb73-947a-490e-a468-60faec8d3eb5",
  "giftCardCode": "",
  "locale": "en",
  "paymentRedirectUrl":
    "https://checkout.stylemachine.art/__events/event-details/<slug>/order/<id>
     ?reservationId=<id>
     &origin=https%3A%2F%2Fwww.stylemachine.art%2Fevents%2F<slug>
     &headlessExternalUrls=~(events-typ~%27...~headlessClientId~%279b14296d-...)"
}

The only field that looks contentious is paymentRedirectUrl, which is on checkout.stylemachine.art.

3. Why that URL is on that domain

This is the crux, and we believe it is a configuration gap we cannot close ourselves.

  • createRedirectSession builds fullUrl on the site’s primary domain: https://www.stylemachine.art/_api/iam/cookie/v1/createSessionCookie?...
  • But www.stylemachine.art resolves to Vercel, our external frontend. It returns 404 for all Wix page routes, so that URL is unusable as issued.
  • We therefore rewrite the host to checkout.stylemachine.art (a subdomain connected to the Wix site). That works: createSessionCookie returns 302 and the ticket form returns 200.
  • The hosted page then derives paymentRedirectUrl from its own origin — checkout.stylemachine.art — and your validator rejects it.

Notably, the hosted page itself reports siteUrl and externalBaseUrl as https://checkout.stylemachine.art. So the page considers that its own domain, while the Redirects API still builds on www. That inconsistency appears to be the root of this.

4. Evidence this has never worked

  • listOrders returns total 0 for the whole site, scoped across all 9 ticketed events including ended ones. Not one order in any state — not even INITIATED, which is created before payment.
  • After we created two test orders via the API, the same call returned exactly 2 — confirming the query is correct and the zero was real.

5. What works vs what fails

Step Result
createTicketReservation OK
createRedirectSession OK
createSessionCookie 302 (after host rewrite)
ticket-form page load 200
orders.checkout (API) Creates INITIATED order — even cross-identity
Hosted form → place order 400 INVALID_PAYMENT_REDIRECT_URL

Calling orders.checkout directly with the same buyer fields succeeds and creates a real order. It sends no paymentRedirectUrl, so nothing is validated — which is consistent with that field being the sole cause.

The event’s registration form is also clean: system NAME (firstName, lastName) plus email, all mandatory, nothing deleted or custom. The payload matches it exactly.

6. Second defect: setting the Wix pages domain crashes your URL builder

Following your documentation, we set the Wix pages domain in Headless Settings. Immediately afterwards every createRedirectSession call failed site-wide — login, tickets and eCommerce alike — with a server-side crash:

TypeError [ERR_INVALID_URL]: Invalid URL
    at new URL (node:internal/url:676:13)
    at buildWixUrl (/opt/app/packages/redirects-api/dist/url-builder/url-builder.js:149:17)
    at buildWixUrlWithHeadlessContext (url-builder.js:87:55)
    at buildWixUrlWithCreateCookie (url-builder.js:245:38)
    at RedirectSessionService.createRedirectSession (RedirectSessionService.js:98:82)

failed-client.method: wix.headless.v1.RedirectSessionService/CreateRedirectSession
requestId: 1789197172.2023213553911426

This took all checkout down for several minutes. We verified the OAuth app was byte-for-byte identical to its previous state throughout, so no client-side configuration of ours was involved. It recovered on its own. A malformed stored domain value should not produce an unhandled ERR_INVALID_URL in buildWixUrl.

7. What we have already tried

Attempt Result
Add checkout domain to allowedRedirectDomains No effect — same error
wixPagesDomainsMappings (origin→destination) Stored (200) but inert — redirect URLs still built on www
redirectUrlWixPages Stored (200) but inert — redirect URLs still built on www
Wix pages domain via dashboard Caused the outage in §6

All configuration changes above have been reverted; the OAuth app is back to its original state.

8. Questions

  1. For a self-managed headless project whose primary domain points to an external host, which domain should createRedirectSession build fullUrl on, and what is required for the Wix-hosted checkout to accept a paymentRedirectUrl on that domain?
  2. checkout.stylemachine.art is currently connected with assignmentType: REDIRECT. Does serving Wix-hosted pages require a different assignment, and if so which?
  3. Is the ERR_INVALID_URL crash in §6 a known defect, and what stored value triggers it?
  4. Our primary domain reports dnsPropagationStatus: FAILED while resolving normally. Is that related?

9. Reproduction

  1. Create a ticket reservation for a ticketed event.
  2. Call createRedirectSession with eventsCheckout: { reservationId, eventSlug }.
  3. Observe fullUrl is on www.stylemachine.art, which 404s (external host).
  4. Rewrite the host to checkout.stylemachine.art; the form loads (200).
  5. Submit first name, last name, email → 400 INVALID_PAYMENT_REDIRECT_URL.

Prepared 12 September 2026 · Style Machine · all IDs and errors captured from live requests

2

Your checkout subdomain is on the wrong assignment type. A redirected Wix domain never serves pages — it forwards to the primary domain and the address bar changes to the primary. So checkout.stylemachine.art forwards to www.stylemachine.art, which now points at Vercel, which 404s. That one fact explains all four of your questions.

Taking them in order.

Q1, which domain fullUrl should be built on. The Wix pages domain. Wix’s own example returns fullUrl on the checkout subdomain, not the frontend domain. Yours builds on www because www is still your project’s primary domain. Fix the assignment and fullUrl follows on its own.

Q2, does serving Wix pages need a different assignment. Yes. The subdomain has to be the project’s primary domain. REDIRECT forwards, it doesn’t serve.

Q3, the ERR_INVALID_URL crash. Check your Login URL field before calling it a defect. Wix’s migration guide warns that if Login URL is set to a callback path instead of a login page, Wix builds invalid login URLs by appending paths to that value. That’s a documented way to get malformed URLs out of the builder. Leave it empty unless you host a custom login page. If it’s already empty and the crash survives the domain fix, then it’s worth reporting as a bug.

Q4, dnsPropagationStatus FAILED. Not unrelated — same cause. Your project still has www assigned, so Wix keeps checking whether www resolves to Wix. It resolves to Vercel. Wix reports the check failed. It clears when you unassign www.

The sequence. Order matters here, Wix’s own guide flags it.

Connect the subdomain. Settings → Domains, connect checkout.stylemachine.art, set it as the project’s primary domain.

Unassign www. Remove www.stylemachine.art, and the apex if it’s connected, from the project.

Set the Wix pages domain. Headless Settings → Manage URLs → Wix pages domain → checkout.stylemachine.art.

Allow the return domain. Headless client settings → Allowed redirect domains → add www.stylemachine.art and stylemachine.art. This is the one that clears INVALID_PAYMENT_REDIRECT_URL. That error is about callbacks.postFlowUrl — the URL Wix returns the buyer to after payment. It has to sit under an allowed redirect domain or the payment step rejects it. Nothing to do with the checkout URL you’ve been rewriting.

Set the Frontend link to https://www.stylemachine.art.

Then remove the Vercel rewrite. Once the subdomain is primary and set as the Wix pages domain, createRedirectSession builds on it by itself. The rewrite is fighting the architecture, and it’s why the validator is seeing a URL it won’t accept.

allowedRedirectDomains and wixPagesDomainsMappings look inert because the primary domain assignment overrides them. They’ll take effect once www is unassigned.

Nine ticketed events and zero orders ever created fits this exactly — nobody has ever cleared the payment step. It isn’t a data or Events API problem.

Refs: