Iver Odin Kvello

We actually don’t use postMessage at all in this code. In the normal case, the “template_redirect”-hook is used to intercept the “continue with vipps” page, do the login handling and then redirect to the correct place (profile page or otherwise).

When I currently go to https://fixformeg.no/wp-vipps-login/continue-from-vipps/ I actually get a server error from your site. Could you go through the server logs and check what they say for about 9. june 2026, 12:00-12:05 CEST ?

Also, if you are using WooCommerce, this plugin will log to a WooCommerce-log called “login-with-vipps”. It should be retrievable from WooCommerce/Status/logs – if you can please check this too.

Hei,

Portalen administreres og utvikles av Vipps selv – dette er forumet for WooCommerce-integrasjonen kun.

Du kan forsøke å henvende deg til Vipps direkte om du har ideer her; vi kan kun sørge for å tilby den metainformasjonen som Vipps tar i mot for transaksjonene.

I’m not familiar with how the Woo Payments plugin works with regard to multi-currency; but you should be able to find out by checking the value of get_woocommerce_currency() while browsing the site with NOK as your customers’ currency. If this then returns NOK, I would expect Vipps to work by just turning it on (and selecting NOK of course). You could just log this or output it in a hidden DIV or something like it. Claude or codex should be able to do that easily.

We can help with debugging if that doesn’t work – it should be no more than a few lines of code, such as

add_action('wp_footer', function () {
    echo "\n<!-- current-currency is " . get_woocommerce_currency() . " -->\n";
    error_log("Current currency is " .  get_woocommerce_currency());
});

— to both log the currency and to print it in a comment in the footer. NB you would need to turn of caching for this to work.

It is not a sloppy workaround per se – if get_woocommerce_currency() returns NOK and the prices have been calculated correctly with norwegian prices, the base currency of the store shouldn’t matter. Only the currency as it is in the moment of purchase.

If Woo Payments only implements switching currencies for its own payment gateway, there may be issues; but it seems like an unlikely way to implement it.

• This reply was modified 1 month ago by Iver Odin Kvello.

WooCommerce har noen standardinnstillinger for å registrere kunder ved kjøp, under “Innstillinger/Kontoer og Personvern”.

Du kan kombinere dette med Hurtigkassen ved å velge Vipps MobilePay/Innstillinger under “Hurtigkasse” – “Opprett nye brukere i hurtigkassen”. De vil da bli opprettet med eposten de er registrert med i vipps.

Hvis du bruker “Login med Vipps” så vil den også kunne brukes sammen med Woo til å registrere kunder med kundens addresse i Vipps.

Hei,

“redirect-url-en” finner du i innstillingene til utvidelsen, som du finner (i nyeste versjon) i “Vipps Mobilepay”-menyen, eller i eldre versjoner under “Innstillinger”.

Et lite stykke ned finner du et avsnitt der det står “Redirect URIen din er …” og der står den, sammen med et lite sett instruksjoner.

Denne URL-en må registreres hos Vipps, fordi det er bare registrerte URL-er som de kan sende deg tilbake til. Dette av sikkerhetsgrunner. Du logger da inn i Vipps-portalen (https://portal.vippsmobilepay.com ), velger “Utvikler”, finner ditt utsalgssted og så velger du “Setup Login”. Der kan du registrere de URL-ene du trenger (hvis du har et utviklingssnettsted og et live-nettsted så registrerer du begge her).

“Pre-ordered” is a custom order status provided by the plugin; of which our plugin is a priori aware. The filter you’ve discovered is provided exactly for this use-case.

As you’ve probably noticed the plugin can also use “On-hold” by changing the settings, but it is absolutely correct to use the filter you’ve discovered to set the “completed order status” to “pre-ordered”.

As for your proposed filter, I’d probably just lose the “break” – it probably won’t save you anything measurable and would stay correct if the plugin later eases its restrictions. But as it stands, it should be fine.

new version is live now; so please check if the issue is resolved when you are ready.

This plugin used to be two separate plugins; that is true; and since these provide two separate payment gateways and uses two different payment APIs they do treat the payment process slightly differently.

However, the Checkout screen should absolutely be capable of handling order-received events and has in fact done so since 2022 – back then we used something very much like your filter to dispatch all order-receiveds to the standard checkout; making the Vipps one slightly less self-contained. This caused some problems in some very rare setups.

https://server.com/kasse/order-received/XXX/?key=YYY *should* in fact exist, as it is a Woo endpoint for the /kasse/ page which is a normal WP page. It should be handled exactly like the standard checkouts’ endpoint, and in fact in exactly the same way, by dispatching to the old shortcode based checkout. If it didn’t exist you should have gotten a 404 here, really.

This *may* have something to do with your rewrite rules, so you may try to go to your Settings/Permalinks and press “save” there without changing anything. If not, it would be great if you could tell us what versions you are using of Woo and WordPress, if you are using Gutenberg or the old checkout screen, and if you are using any other “Checkout” style plugin that modifies the normal checkout logic.

Aside from that, your filter for ‘woocommerce_get_return_url’ is correct and should not cause any issues as long as you don’t delete the original checkout page or something like that.