Viva.Com Order Cancellation Gives 404 Error

[Belkin]

Got it — here’s a more written Geordie tone, less spoken but still regional:
Sorry, it’s me again. I’ve got another issue with the viva.com smart checkout setup, so I’ll keep this brief.
When a customer clicks the checkout button, they’re shown the checkout screen. After clicking “proceed with payment” (or similar), they leave the store and are redirected to viva.com’s hosted payment page.
If, at that stage, the customer decides to cancel and not continue, they’re expected to click the small cancellation link in the top-left corner. However, doing so results in a 404 page being displayed. This is pretty poor, and the fix is clearly needed on viva.com’s side.
I’ve already contacted support, but I’ve no idea when the ticket will be picked up.
Below is what the cancellation link looks like — https://MyEstore.Name/wc-api/wc_vivacom ... B&cancel=1 where ****** is the session ID
when this address appears in the adress bar - it triggers the 404. Is there any workaround for this?
Sorry for being a bit noisy this evening.

[Webmaster]

Right, listen in, because I’ve been round the houses with a similar one and it's a right old touch-and-go situation. If you’re using the Viva.com (Vivacom) payment gateway for WooCommerce and find that your "Cancel" redirect is sending folks to a dead page or a messy API link instead of back home, here’s the skinny on how to fix it.

We were trying to get anyone landing on that payment_fail nonsense to be whipped straight back to the homepage. Here’s the post-mortem on what we tried before we found the winner.

The "Old School" Redirect Plugins
What we tried: Using standard WordPress redirection plugins. Why it failed: These plugins are alright for basic pages, but WooCommerce API paths are a bit "posh"—they load up before the plugins even wake up. The plugin doesn't even see the user pass by, so it can't redirect them.

The .htaccess / Apache Route
What we tried: Writing rules into the .htaccess file and the "Additional Apache Directives" in the hosting panel. Why it failed: A lot of modern hosts use Nginx as a "reverse proxy" (like a bouncer at the door). If the bouncer doesn't like the look of the request, it never even reaches Apache. We were shouting instructions at a room the user hadn't even entered yet.

The JavaScript "Bouncer"
What we tried: A bit of script in the header to tell the browser to jump ship. Why it failed: To be honest, it’s a bit of a "cowboy" job. It’s slow, and if a customer has a fancy browser setup, it can block the redirect. We wanted something "proper" that happens on the server, not the user's kit.

The Proper Result: The Nginx Location Block
If you’re on a server with Nginx (like most Plesk or high-speed setups), you’ve got to talk to the "main man" directly. You need to put this in your Additional Nginx Directives.

The Code in your case (make sure you gave correct path in your):

Nginx

Code: Select all

location ~* wc_vivacom_smart_fail {
    return 301 https://your.site/;
}

Why it works: This doesn't muck about. It tells the Nginx server: "The second you see anything with wc_vivacom_smart_fail in the name, don't ask questions, just send 'em to the homepage." It’s clean, it’s fast, and it works before the site even tries to load.

Sorted!

[Belkin]

Thanks for the thorough explanation, much appreciated. That said, I’m not really getting what this is about or how it applies in this case — it’s gone a bit over my head, like.
I reckon I’d better get my techie mate to have a proper, deeper look into it later on tonight and see if he can make sense of it.

Cheers again for taking the time to explain, much appreciated.

[harepon207]

You’re not being noisy at all—this is a valid issue. The 404 error is likely caused by the cancel URL (wc-api/wc_vivacom) not being properly handled by your WooCommerce setup rather than entirely a viva.com problem. This endpoint should be registered by the plugin, and if it isn’t, WordPress returns a 404. A quick fix is to refresh permalinks by saving them again in settings, ensure the Viva plugin is active and updated, and check for plugin conflicts. You could also try setting a custom cancel URL if supported. Otherwise, it may still require support intervention.