Rune Rasmussen

According to Svea there is no payment link sent on SMS for test, but it seems to work for production.

It’s though not sent any mail from Svea or the store automatically when using either test or production, even though the order states that a payment link it’s sent, but maybe you’re just displaying duplicated info with different wordings:

Svea instore
Payment link is sent
SMS sent successfully

• Note! Maybe anyway better to display different messages her when in test mode, to avoid any confusion.

Anyhow for others wondering, this seems to be the steps working somewhat:

1. Create a manual order as you normally would from admin (Google: Manual order in WooCommerce), with status ‘Awaiting payment’.
   *On payment method you should probably select Svea Checkout, even though it doesn’t seem to make any difference?
2. Click on ‘Create’ in the ‘Order action’ box.
   *NOTE! Do not select any email to send, the payment link in it will not work at this stage, and thus only confuse your customer.
3. Wait for the page to reload.
4. Click the new ‘Send Svea payment link’ button, who should appear in the order details box now.
5. Wait for the page to reload.
6. The customer should receive a SMS with a payment link from Svea.
7. Now you can also select the ‘Send the order details to customer’ in the ‘Order action’ box, if you also want to send a payment link on mail.
   *Select it from the drop-down, and just push the “arrow” next to it to send it.
8. The customer receives the order details mail including a payment link.

Regarding “minutesUntilLinkExpires”, this is set in WooCommerce > Settings > Products > Inventory.
It is the setting called “Hold stock (minutes)”.

Okay, but what if stock management isn’t enabled then? When ‘Manage stock: Enable stock management’ isn’t selected, the ‘Hold stock (minutes)’ setting is hidden, but you still use it?

Obviously I already did step 1-3, and it didn’t work, so not exactly what I was looking for no. ??

Beyond that, great that we agree there is a need for docs. Though we’ve been waiting for several things more than a year, so patience is slowly running out. ??

PS! T.ex. this would probably help for line 3648:

$float_sale_price = floatval($product_data['sale_price'] ?? '');

And then you probably can reuse it in line 3656 etc., or do something similar there.

Obviously not. The question now is if you will predefine it as empty, or check if it’s actually defined before trying to use it, to avoid the PHP Warning message, correct the code for PHP 8+?

I can’t confirm that atm, but anyhow, a sale price shouldn’t be required.

The required empty define or fallback should rather be handled in the plugin code, shouldn’t it?

Great, would be awesome if you at the same time would look at the newer ending issue with newsletter signups etc, since it probably is somewhat related (t.ex. https://www.ads-software.com/support/topic/woocommerce-checkout-page-hooks/).

I faq.txt som ligger i pakken st?r det f?lgende:

Why do rates not show up on the cart page?
Bring rates are only shown when the customer has entered a valid postcode. Commonly customers have either entered the wrong postcode or live outside of your Bring postcode settings.

But the postcode is valid and the rate still isn’t showing?
If you’ve entered any Mybring details, try removing them. If Bring shows up on the cart page after they’re removed, it suggests that your details may be incorrect. If it’s still not showing after that, you should check that all the settings are correctly filled out.

Om dette ikke setter deg p? sporet, fors?k ? gi litt mer utfyllende informasjon om innstillinger m.m., men p?se ogs? at produktene du tester med har vekt og evt. m?l (om du ikke har valgt ‘Ignorer produktdimensjoner’ i innstillinger), evt. sjekk alternativene for tilbakefall i utvidelsen. P?se ogs? at du har et gyldig fra postnummer.

Er helt sikkert bare noe du har oversett et sted. ??

Any news on this?

Maybe you need a checklist to follow when releasing new versions?

And also, don’t try to hide mistakes or other changes, always log everything. In this case, if someone manually updates (t.ex. by ftp), they should also know about this particular mistake, so they can delete the folder (even if it was out just a short time).

For everyone interested it seems to have been caused by Svea sending two validation callbacks in less than a minute, and for whatever reason those two calls have been processed at the exact same second in Woo. This then somehow seems to have changed the order status twice ( Pending payment -> Processing -> Pending payment), and made them show up in reverted order in the order notes. This is at the moment the only plausible explanation.

Svea on their side should maybe give it some more time, before sending another validation callback, waiting for whatever confirmation the plugin delivers (Push callback finalized order?), because delays happens – it’s internet.

The plugin on the other side should probably ensure it doesn’t process two identically validations callbacks, and at least ensure the order status isn’t already ‘Processing’ before trying to update it again.

Thus I would recommend looking at how it could end up as ‘Pending payment’, going from ‘Processing’ to ‘Pending payment’ – as that plausible is what happened. Looking if there is anything in the plugin code allowing that to happen (which it shouldn’t), or if it just was a odd consequence of the status update collision (which of course shouldn’t happen).

• This reply was modified 5 months, 3 weeks ago by Rune Rasmussen. Reason: Typos

Btw! Also Secret/secret is not consistent with Svea’s own wordings, as they writes ?SecretWord? in their credentials mails etc. – and as it’s a name it should be written with first letter uppercase (S) also inside strings (?Merchant ID and SecretWord must be set to use Svea Checkout? not ?Merchant ID and secret must be set to use Svea Checkout?).

Also a minor issue though, but overall it looks sloppy. ??

Btw! Shouldn’t also all those Instore strings where you now have written t.ex. ?Instore PaymentAdmin secret – Global? rather be ?Instore Secret – Global?, as Svea Payment Admin really doesn’t have anything to do with those?

If you make me the Translation Editor for Norwegian, I’ll get them approved and ready more frequently, and you don’t have to remember doing it. ??

Great, let’s hope it’s being improved then.

Btw! Since you already have the settings for each country in separated sections, with country name as title, it’s not really necessary to repeat the country names in those strings either. Though it doesn’t hurt do be clear, as long as it’s done more translator friendly. ??

If you want to display your prices such as “2200 kr” then you can use the snippet provided earlier:

As mention that’s not a solution who is good enough for several reasons.

This is especially true since WooCommerce works on a order row basis (example; 100 kr for 2 items) while Svea uses unit pricing (example; 50 kr per item, 2 items).

Then that should probably be considered changed, or you could do the correct calculation beforehand in the plugin.

Anyhow you have said the issue is that you get the wrong tax rate from your calculations, so if you can pull it directly instead of trying to calculate it, it would end up right altogether. ??