=== Von Payments for WooCommerce ===
Contributors: vonpay
Tags: woocommerce, payment gateway, credit card, checkout, payments
Requires at least: 6.4
Tested up to: 7.1
Requires PHP: 7.4
Stable tag: 0.5.30
License: GPLv2 or later
License URI: https://www.gnu.org/licenses/gpl-2.0.html

Accept card payments through Von Payments (Vora) on your WooCommerce store, with native on-page checkout on both the classic and Blocks checkout.

== Description ==

Von Payments for WooCommerce lets your store accept card payments through Von Payments. Card details are entered inline on your checkout inside a secure Von Payments iframe, so your store never handles raw card data and stays PCI SAQ-A. Works on both the classic and the block-based ("Cart & Checkout Blocks") checkout.

Apple Pay and Google Pay are offered alongside the card form when your Von Payments account and your store's domain are set up for them and the shopper's device supports them. The buttons appear once the shopper has filled in the details an order needs. When a shopper approves a wallet payment the amount is reserved on their card rather than taken, and it is taken when the order is placed, so a payment that cannot become an order is released instead of needing a refund.

== External services ==

This plugin connects your store to Von Payments (Vora), a third-party payment service, to create checkout sessions, process card payments, issue refunds, and receive payment status webhooks.

* Data sent: order amount and currency, order reference, and (from the buyer's browser, inside the Von Payments iframe) the card details the buyer enters. The plugin's server code transmits your Von Payments API keys and order metadata; it never transmits raw card numbers.
* When: at checkout, on refund, and when your store's webhook endpoint receives a payment update.
* Service: Von Payments. Terms: https://vonpay.com/terms | Privacy: https://vonpay.com/privacy | API endpoint: https://checkout.vonpay.com

You must have a Von Payments account and paste your own API keys into the gateway settings for this plugin to function.

== Changelog ==

= 0.5.30 =
* Added: Apple Pay and Google Pay at checkout, on both the current and the older checkout, for stores whose Von Payments account and domain are set up for those wallets. The buttons appear once the shopper has filled in the details an order needs. The money is reserved on the shopper's card when they approve the payment and taken once the order is placed, so a payment that cannot become an order is released rather than refunded.
* Added: a "One-click add-ons" setting, off by default. When you turn it on, the card a shopper pays with is kept so an offer made after the order can be charged to it without the card being entered again; upsell code takes a token for the order with vonpay_upsell_token() on the thank-you page and charges the offer with vonpay_charge_upsell(). An accepted offer becomes part of the order the shopper already paid, as a payment of its own: its products are added and the order total grows only once that payment has gone through, so the total is always what was actually paid. No second order is made, the order's status is never changed by an offer, and no email is sent for one; each outcome is a note on the order. If the shopper's bank asks to check an offer, the shopper is brought back to the page the upsell chooses and the offer is settled before that page shows, and vonpay_offer_result() tells the upsell where an offer stands. A refund is split across the order's payments without asking any payment for more than it took, and refunding an offer's lines refunds that offer. An offer's payment that went through but could not be added, for example after the order was cancelled, is given back automatically. The upsell token is issued only in the first 30 minutes after the order is paid, works only for the shopper it was issued to (a token for a guest order issued where there is no store session, such as from a REST call, works for whoever holds it, like the order's own thank-you link), and pays for one offer. An offer can add any product the store sells at its own price, including a bundle, which is added as one line; never a subscription. A card kept only for this is recorded on the order, is not listed in the shopper's saved cards, and the shopper is told at the card form. A guest's card is kept by the email they enter, when they enter it before typing their card.
* Fixed: an order paid with a saved card that was left on hold, because the bank did not answer in time or asked the shopper to confirm, was completed only if the Von Payments notification reached the store. The plugin's own check every 15 minutes now asks Von Payments about these orders too: it completes one that was paid, marks one that failed as failed, and gives up on one still unconfirmed after a day with a note asking you to check the Von Payments dashboard.
* Added, with the wallets above: if the store loses the moment a wallet payment is taken, for example because the shopper's connection drops, the plugin's 15 minute check finds the reserved money. An order whose payment was already taken is completed. An order whose money is still only reserved is put On hold with a note: choose "Take the held wallet payment" from Order actions to take it, or cancel the order to give the money back. The order is completed only once the payment has actually been taken. Changing the status by hand does not take the payment; the order note says so.
* Fixed: the plugin's 15 minute check for orders whose payment confirmation was lost could stop working on a store with 20 or more unpaid orders older than the one that needed it, such as abandoned checkouts, while still reporting itself as healthy. It now skips orders it can do nothing about, looks at on-hold orders first, and stops asking about an unpaid order after a day without changing it.
* Fixed: dismissing the warning that Von Payments cannot reach your store with payment updates hid it for every administrator, not only the person who clicked. Each person now dismisses it for themselves, so a shop manager can no longer take it off the owner's screen. Because nobody can tell who dismissed it before this update, anyone who had dismissed it will see it once more if the problem is still there.
* Changed: the card form is now only ever loaded from Von Payments' own script address. The vonpay_vora_script_url filter still lets a developer choose a specific build on that address, but any other address it returns is ignored, the standard card form is loaded instead, and the WooCommerce log records the ignored value once a day. This stops any other code on the site from swapping the card form for one that could read card numbers.
* Changed: the tools used to build the block checkout script were updated. The script behaves exactly as before; only the code WordPress uses to load it changed slightly.
* Fixed: when a shopper cancelled or failed their bank's security check, the order was put on hold with a note saying a later update would finish it, which was not true, and the shopper saw an ordinary order-received page. The merchant now gets one plain note saying the bank did not confirm the payment, and the shopper is told the same. The order still stays on hold, because the payment service cannot yet confirm that nothing was charged.
* Fixed: a saved card whose last four digits or expiry date Von Payments did not provide was shown as ending in 0000, with an expiry date five years away. Those details were placeholders WooCommerce needs in order to save a card at all, not the card's real details. The card is still saved and still works, but its digits now show as •••• and its expiry as unknown, in the account page, both checkouts and order notes. Cards saved before this update that show 0000 are shown as •••• too; that includes a card that really does end in 0000. Their expiry date is shown as stored, because the old placeholder cannot be told apart from a real date.
* Security: the Von Payments settings page no longer contains your saved secret keys or webhook signing secret in the page itself. Before, they were hidden on screen but readable by anyone allowed onto that page who viewed its source, including Shop Managers. A saved secret now shows as "Saved. Leave blank to keep it." Leaving the field empty keeps it; to remove one, tick "Remove the saved value when I save" under it.
* Fixed: when a shopper paid with a saved card and their bank asked to confirm it was them, the shopper was shown the order-received page instead of their bank's check, and the order stayed on hold because the payment could not finish. The shopper is now sent to their bank's check and brought back to their order, which completes once the bank confirms.
* Changed: when a shopper comes back from their bank's security check and the bank has not answered yet, the order page now says "Payment not confirmed yet" and checks again by itself, instead of looking like a completed order. For a saved card, the order page asks Von Payments as it opens and then every 2 seconds for about a minute, so a payment the bank has already approved shows as paid straight away. A paid order that you later put on hold is not shown to the shopper as waiting on their bank. As soon as Von Payments confirms the bank declined the payment, the order is marked failed and the shopper is taken straight back to the checkout with the same items, the order's coupons and a message saying why, on both checkouts and for saved cards; Apple Pay and Google Pay do the same when the bank refuses the payment. A coupon that is no longer valid is left off and the shopper is told which one. If the shopper opens the order's page later, it still shows "Order failed" with "Try again". If the shopper has already left, they are not emailed: walking away during the bank's check is treated as an abandoned checkout. When nobody could confirm that nothing was charged, for example an order the plugin's 15 minute check gave up on after a day, the shopper is never sent back to pay again or told they were not charged: the order's page and its "Try again" say the store could not confirm whether the payment went through and ask them to contact you instead of paying again.
* Changed: after a card is declined, the shopper can pay with another card, or a saved card, straight away. Before, they were often asked to wait 30 seconds or two minutes first, to rule out paying twice. The declined attempt is now closed with Von Payments, which confirms it can never be charged, so no wait is needed. A short wait remains only in the rare case where Von Payments cannot yet confirm that.
* Fixed: a saved card could be charged for an order that had already been cancelled, for example a subscription renewal order cancelled before its payment ran. The money was taken, the order stayed cancelled, and the charge had to be refunded by hand. A cancelled order is now never charged.
* Changed: when one order is being paid two ways at almost the same moment, such as a saved card in one browser tab and a new card in another, the second is now asked to wait a moment and try again, so the shopper cannot be charged twice. Nothing is taken for the attempt that waits.
* Changed: a store that has opted in to pre-release builds can now receive them. Opting in takes a line in the site's configuration file that no store has unless someone adds it by hand, so this changes nothing for any other store.
* Fixed: a card the shopper ticked to save was not saved, and the card for one-click add-ons was not kept, when the shopper's bank asked them to confirm the payment, and on some payments without that check too. The plugin now asks Von Payments which card the payment used when the shopper comes back from their bank, when the payment notification arrives, and at checkout, and keeps it only if the shopper ticked the box, or for add-ons when that setting is on. The order notes now say whether the card was saved and, if not, why.
* Added: your store can now act on the Von Payments notice payment_method.attached, sent when a card a shopper chose to save is linked to their payment only after the payment was confirmed, so that card is saved as soon as Von Payments links it. The notice is optional: add it to your webhook endpoint once your Von Payments dashboard lists it. Without it, the store asks Von Payments again twice in the first few minutes after the payment and then every hour for a day; a subscription bought with that payment is put on hold only if no card has turned up by the end of that day.
* Fixed: a shopper who did not finish their bank's security check was told their bank had declined the payment: on the "Order failed" page, by its "Try again" message and, for a saved card, at the checkout. Nobody had declined it, and nothing was charged. They are now told the check was not completed, that they have not been charged and to try again, and the order note says it was not a decline.
* Fixed: if the order total changed after the card form loaded, for example a shipping choice made just before the order was placed, the card was charged the old amount and the order was put on hold for you to sort out. The checkout now stops before anything is charged, tells the shopper "Your order total changed. Please review it and place your order again.", and loads the card form again for the new total.
* Fixed: a shopper with the checkout open in two browser tabs who changed their basket in one tab could pay in the other and be told "We could not confirm this payment" although the card was charged. The order then waited for the payment notification or the plugin's 15 minute check. That payment is now confirmed straight away.
* Changed: when Von Payments refuses a request, the WooCommerce log now records it as a warning rather than an error, so the errors in the log are the ones worth looking at. Warnings are written whether or not debug logging is on. Two answers the plugin expects and handles, a declined payment session that cannot be closed yet and a saved card Von Payments has no record of, are logged only when debug logging is on. A failed Apple Pay file download now shows the Von Payments reference to quote to support.
* Fixed: when Von Payments refused a saved card payment for a reason that was not the shopper's bank, for example a setting it needed, the shopper was told their card was declined and to use a different card, and the order note said no reason was given. The shopper is now told the card could not be charged right now and that they have not been charged, and the order note gives the reason and the Von Payments reference. A real decline from the bank is still described as a decline.
* Added: if the same order is refused twice because its total does not match the total the checkout sent for payment, the store is treated as the cause rather than a changed basket, for example a plugin that adds a fee or converts the currency when the order is created. The shopper is asked to contact you, the order gets one note with both totals, and a warning appears in your WordPress admin until a card checkout's totals match again.
* Fixed: the payment reference shown on an order could be the card processor's own number instead of the Von Payments reference.
* Added, with the wallets above: when a shopper's bank asks to check an Apple Pay or Google Pay payment, the bank's page opens in a pop-up on your checkout, so the shopper does not leave it. When the check passes, the payment is taken and the shopper sees their order as usual. When they close the check and Von Payments confirms nothing was charged, they stay on the checkout and are told their bank's security check didn't go through. When the check fails, they are brought back to the checkout with the same items and the same message. When the bank has not answered yet, the order waits for its answer and the shopper is not invited to pay again. Where the pop-up cannot open, for example when the page's security settings do not allow it, the shopper goes to the bank's own page instead and comes back to the store afterwards.
* Changed: while a shopper's bank has not answered its security check, WooCommerce's "order on hold" email is no longer sent; the order page says the payment is not confirmed yet. WooCommerce's own failed-order email to the shopper is no longer sent for any order paid with Von Payments. Before, a store on WooCommerce 9.5 or later sent it, telling the shopper to pay another way, including for a failure nobody had confirmed. The failed-order email WooCommerce sends to the store itself is unchanged.
* Fixed: WooCommerce no longer cancels an unpaid order while its payment may still be at the shopper's bank, for example when the shopper closed the tab during their bank's security check. Such an order is kept for a day from when its payment was started, so a payment the bank approves late still finds its order; after that WooCommerce's usual rule for unpaid orders applies again.
* Changed: when a shopper's bank security check does not pass, or they cancel it on their bank's page, they are told "Your bank's security check didn't go through, so you have not been charged. Please try again or use another card." on the checkout and on the order page, the same words as for a check they did not finish, and the order note says it was not a decline.
* Fixed: on both checkouts, a shopper who closes the window of their bank's security check on the card form, or lets it run out of time, is told they have not been charged and can press Place order again with the card already entered. Nothing was charged, so the order is not marked failed and no email is sent. The same fix lets the block checkout's card form be used again after it resets itself following a decline, which Von Payments does not do yet.
* Fixed: when a shopper closes the bank's security check for an Apple Pay or Google Pay payment, or lets it run out of time, and comes back before the payment's own record shows it ended, the store now asks Von Payments to close the checkout. Von Payments agrees only once the bank's check has been ended and nothing on the checkout can take money, which is the case when it has already ended the check at the shopper's request; the shopper is then brought back to the checkout with the same items and the same message. While the check is not yet ended, or for a checkout that has used up its tries, Von Payments refuses, and the order page is shown as before until the plugin's 15 minute check finds the answer. If two orders were paying at once and either still has, or may have, the shopper's money, the shopper is shown that order instead of the checkout.
* Changed: a shopper is not emailed when a payment fails. A shopper who is there sees the result on the checkout or on the order's page; one who walks away during their bank's security check is treated as an abandoned checkout and gets no email, and the order is marked failed with a note saying what happened, for example that the check was not completed and nothing was charged. A payment the bank approves after all completes the order, and WooCommerce's usual order confirmation is sent.
* Added, with the wallets above: when the shopper's bank refuses to take or give back a reserved wallet payment, the order note says so and that the money is still reserved on the shopper's card unless the hold has expired, and a payment the store asked to give back that is still reserved stays on the Von Payments warning on the dashboard. When Von Payments cannot say whether a wallet payment was taken, the plugin asks Von Payments where the money is before doing anything, never treats it as still reserved on that answer alone, and tells you not to try taking it again until its hourly check has looked, so the money cannot be taken twice. A wallet payment found to have been taken for a different amount than the order's total does not mark the order paid. A paid-for offer whose reserved payment the store could not give back after a day says so in its note.
* Changed: Test mode and Live mode now each keep their own webhook signing secret, in two fields on the settings page, because your test and live Von Payments accounts each have their own webhook endpoint with its own secret. The store checks each payment update with the secret for the mode it is in, so switching between Test and Live mode no longer quietly stops payment updates, and if the mode you switch to has no secret saved, saving the settings tells you so. The secret you already saved keeps working with nothing for you to do: on a store in test mode it moves to the test field, and on a store in live mode it stays in the live field.
* Fixed: when a customer disputes a payment (a chargeback), the order note told you to respond in your Von Payments dashboard, which has no dispute screen. The order notes and the log now tell you to respond, and submit any evidence, in your payment processor's own dashboard, where disputes are handled, and to reconcile a lost dispute there too.
* Fixed, with the wallets above: on the block checkout with Apple Pay or Google Pay turned on, a card payment could be refused with "We could not verify your payment session. Please try again." The card form and the wallet buttons each set up their payment at the same moment, and whichever finished second could erase the other's record. Both records are now kept. The same could happen, more rarely, without the wallets, when another part of the checkout saved the shopper's details at that moment.
* Changed: an order paid with a saved card now names the card, for example "Credit / Debit Card (Visa ending in 1072)", as an order paid with a card typed at the checkout does.

= 0.5.29 =
* Fixed: when a saved card could not be charged, the block checkout showed the store's own order note instead of a message written for the shopper, and that message was then left behind: the shopper's next attempt, even with a different card, was refused with "Your saved card was declined" before any payment was tried.
* Fixed: a saved card Von Payments has no record of for your store, which can happen after a card was saved under a different Von Payments account, was reported as declined. The shopper is now told the card can no longer be used, and the order note says nothing reached the bank.
* Fixed: a saved card the payment service has no record of could not be removed from the account page. Every attempt said the removal could not be confirmed and asked the customer to try again, which could never succeed, leaving a card that could be neither used nor removed. The plugin now asks the payment service a second question that names no customer, and removes the card when the answer is that this store has no such card.

= 0.5.28 =
* Fixed: right after a declined card, the card field could show "The secure card field could not load" until the shopper pressed Try again. It now sets itself up again automatically a moment later.
* Fixed: for an order whose first card payment was started before 0.5.24, a brief conflict with another request on the same order could make the store lose track of that earlier payment. It now stops and asks the shopper to try again instead.

= 0.5.27 =
* Changed: the 30 second pause before paying with another card after a decline, added in 0.5.26, now also covers an order open in more than one browser tab, and orders whose first card payment was started before 0.5.24.

= 0.5.26 =
* Fixed: when a card typed at checkout was declined, the block checkout showed "Something went wrong. Please contact us to get assistance." instead of saying the card was declined. It now says so plainly, next to the payment options, and on both checkouts a failed card payment is described in words written for shoppers.
* Changed: after a declined card, a saved card for the same order can be used 30 seconds after the declined payment, once Von Payments confirms it is closed with nothing taken. The two minute wait added in 0.5.24 now applies only while the declined payment is still open, and the message says which wait applies and why.
* Fixed: after a declined card, the card field could fail to load ("The secure card field could not load"), and refreshing did not help, because the store reused the declined payment session, which Von Payments had closed. The store now starts a new one as soon as Von Payments confirms the declined one is closed. Paying with another card within 30 seconds of the decline asks the shopper to wait a moment first, so nobody is charged twice.

= 0.5.25 =
* Fixed: when two requests for the same order reached your store within about a second of each other, for example a payment notification and a second click on the pay button, a safety check could decide on an out of date copy of the order. It now reads the order as it is at that moment. The worst case was a saved card charged for an order that had just been paid, or a payment with no matching order dropping off the warning about them. This needed two requests for one order at almost the same moment.

= 0.5.24 =
* Fixed: a shopper whose card was declined could not then pay with one of their saved cards for the same order until the checkout timed out, and was told their payment session could not be verified. Your store now asks Von Payments whether the declined payment took anything. If nothing was taken and nothing is still being processed, the saved card is charged and the order notes say so. If the first payment might still go through, or was started less than two minutes earlier, the shopper is asked to try again in a few minutes, so nobody is charged twice.

= 0.5.23 =
* Fixed: when two refunds reached your store in the same second, the warning about payments with no matching order could lose track of one of them, so a refunded payment stayed listed even though the log said it had been cleared. Changes to that list now happen one at a time.
* Your store now recognises the label Von Payments is adding to its test notifications, and a labelled test changes nothing on any store, including one using test keys. Until that label reaches your account, a store using test keys behaves as it did before, and a store taking live payments already ignores tests.
* Fixed: if your site configuration named a Von Payments address that was not recognised, the notice said payments were real even when your store was in test mode. It now says which is true.

= 0.5.22 =
* Fixed: a test notification sent from the Von Payments dashboard could change a real order. The dashboard lets you name one of your own checkouts when you send a test, and the test then carries that checkout's real amount, so it could mark an unpaid order as paid, mark a waiting order as failed, or record a refund that never happened. On a store taking live payments, a test notification now changes nothing, and the log says it was a test. On a store using test keys, a dashboard test is still applied to your orders the same way a test payment would be, because the two cannot yet be told apart. No real money is involved on a store using test keys either way.
* Fixed: a payment with no matching order kept being counted after it had been refunded in full. The warning about it told you to refund a payment that had already been refunded, and doing so never cleared it. A full refund now clears it, and the warning updates straight away.
* When every payment with no matching order is test money, the warning now says so plainly, instead of saying that a customer paid and received nothing. A warning left behind by an earlier dashboard test now says it was a test payment, and you can dismiss it.
* Notifications that match no order and involve no money, such as the test your store sends when you press Check webhook delivery, are now written to the log as plain information rather than as warnings.

= 0.5.21 =
* No change to how the plugin works. This version corrects the notes for 0.5.18 and 0.5.20 below, which described a change to what a shopper can do after a declined card as if it had reached your store. It never reached any store.

= 0.5.20 =
* Withdrawn before it reached any store: the change listed under 0.5.18 that let a shopper whose card was declined switch straight to a saved card. We removed it because if the connection dropped at the wrong moment it could charge a shopper a second time, and preventing that matters more than the convenience. Your checkout behaves as it did before 0.5.18: a shopper whose card is declined still cannot switch to a saved card until that checkout expires. 0.5.24 changes this, with a check that asks Von Payments first.
* When an automatic subscription renewal finds an order that money has already moved on, it now leaves a clear warning for you to check instead of quietly reporting the payment as taken. This cannot happen on any store today, because automatic renewals are switched off in this plugin. The change is part of the code that will handle them.

= 0.5.19 =
* Fixed: during a brief interruption at our end, your store could tell a shopper their card had not been charged when it may in fact have gone through, and if they tried again with a different saved card they could be charged twice. Your store now treats an interruption as an unknown outcome unless our service states plainly that nothing was taken, which is the safe direction. The fix itself was already in the previous version; this note is the part that was missing.

= 0.5.18 =
* Stops an automatic subscription renewal from charging an order that has already been paid. This cannot happen on any store today, because automatic renewals are switched off in this plugin. The fault was in part of the code that will handle them.
* This version also let a shopper whose card was declined switch straight to a saved card instead of waiting for the checkout to expire. That was withdrawn in 0.5.20 before it reached any store, so it is not in the version you have.

= 0.5.17 =
* Fixes a bug where a shopper who reloaded the checkout page could be charged and then shown a payment error, leaving the order unpaid until a background job caught up. Also stops an already-paid order being charged a second time with a saved card, and stops a payment service outage being reported to the shopper as a declined card.

= 0.5.16 =
* Added: the groundwork for a store to be set to receive builds before they are released to other stores, for test stores run by people who want to try each build first. It is switched on in the site's configuration file, not in the settings screen, and an ordinary store is not affected in any way. Note that it cannot be used yet: the key that signs those early builds does not exist in this version, so a store switched on now would be offered no updates at all until a later version. The plugins screen says so plainly if you do switch it on.

= 0.5.15 =
* Our payment service now includes its own transaction reference on the notifications it sends your store after a payment, and your store reads it. Until now that notification named the transaction by the card processor's reference, and your store had to work out that it belonged to the payment it had just confirmed; it did so by taking the first such reference it saw for an order to be that order's own, which in principle could absorb a second charge for the same amount. When the notification carries our own reference, your store now matches it directly to the payment it confirmed at checkout and records the processor's reference as a fact stated alongside it, with nothing assumed. A notification that does not carry the new reference is handled as before, with one refinement: a store whose earlier version had recorded the card processor's reference in place of ours now compares later notifications against that reference too, so a genuinely different one is reported instead of assumed to be the same payment.
* Your store now keeps a second payment reference for every order confirmed at checkout, the one an automatic subscription renewal must be tied to. Subscription renewals remain switched off in this plugin; this is groundwork, and it changes nothing about how any payment is taken today.
* Fixed: the webhook check on the settings page reported "Not working" on every correctly set-up endpoint, because it asked for three dispute events that the Von Payments dashboard does not offer and that Von Payments sends to every endpoint anyway. An endpoint subscribed to everything the dashboard offers now passes the check.
* Fixed: an order put on hold because a payment notification stated an amount that did not match the order total could later be marked paid by a notification that stated no amount at all. It now stays on hold until a notification states the right amount, and says so in the order notes.
* Order notes that report a problem, such as a payment already recorded against another order or a refund that could not be matched, are now written once per distinct problem rather than once per delivery. Our payment service retries deliveries and a merchant can resend them, and neither should pile up identical notes on the one order you most need to read.
* This update reaches every store. The matching described in the first item is unchanged on a store whose payment service has not yet begun sending the new reference; the other items apply everywhere.

= 0.5.14 =
* Fixed: after an ordinary successful payment, your store could show a warning saying a payment had been taken that no order accounts for, and the number in that warning went up with every sale and never came down. The warning was wrong. Our payment service refers to one and the same transaction by two different reference numbers, one on the confirmation your store receives at checkout and another on the notification it sends afterwards, and your store read the second as a different payment. It now recognises them as one. The warning clears on its own within about fifteen minutes of updating, and your orders were paid correctly the whole time.
* Fixed: the same mistake meant the after-the-fact notification for a normal payment was being ignored, so the safety net that settles an order when the checkout confirmation itself fails was not working. It works now.
* Fixed: an order that WAS settled by that notification rather than at checkout could not be refunded from WooCommerce, because the reference your store had kept was one our payment service does not accept for refunds. For orders settled after this update, your store now keeps a reference a refund will accept, whenever the notification states the amount paid, which ours do. An order settled that way on an earlier version keeps the reference it already has: trying to refund it from WooCommerce now tells you so and names the reference to use in the Von Payments dashboard, instead of failing with no explanation.

= 0.5.13 =
* Fixed: a customer whose card needed their bank's extra confirmation step was refused before that step could even be offered, and was told their card had been declined. Saved-card payments now tell the payment service where to send the customer back to after their bank has asked them to confirm. Nothing is sent on an automatic renewal, where there is no customer at the screen to confirm anything.
* Fixed: a customer who fixed a declined card and tried again got the same decline, every time, because your store repeated the original request instead of making a new one with the new card. A different card is now genuinely a new attempt. Two attempts with the SAME card at the same total are still treated as one, so pressing Pay twice by accident cannot charge the customer twice.
* Fixed: when a payment attempt never reported back, your store told the customer their card was declined. It could not know that, and the customer may in fact have been charged, so saying "declined" invited a retry that could take the money a second time. Your store now holds the order instead, records the payment reference the payment service reports, and lets the confirmation settle it. If an earlier attempt is still unaccounted for and the order total has since changed, your store will not charge at all, and explains in the order notes what to check first.
* Fixed: an order held because the payment did not match the order total could be marked paid anyway, moments later, by the payment confirmation arriving from our servers. Your store put the order on hold correctly, and then completed it without re-checking the amount, so the hold delayed the wrong outcome rather than preventing it. The confirmation step now applies the same check, and an order whose payment does not match its total stays on hold with a note explaining what to do. A confirmation that does not state an amount at all is still accepted, as before, because not every payment service sends one.
* Fixed: if a card was charged twice for one order, the second payment replaced the first in your store's records and the first could no longer be refunded from WooCommerce. The order now keeps the payment that matches its total, and the earlier payment is reported in the order notes and in the list of payments that no order accounts for, naming the reference you need to refund it. Your store can now tell you the customer has been charged twice instead of losing the evidence.
* Corrects the note published with 0.5.12. That note said a retried payment could come back approved for the original total and mark an adjusted order paid in full. It could not: our payment service refuses a reused request whose details have changed, rather than repeating the old answer. The real problem, which 0.5.12 did fix, was that such an order could not be paid on this payment method at all. No change to how any payment is taken.
* A multi-currency plugin can no longer change which currency your store charges in, or how the amount is scaled, after the order was saved.

= 0.5.12 =
* Fixed a way a repeat payment could leave an order permanently unpayable. If a payment with a saved card came back unclear, the order is put on hold, and the usual next step is to adjust the order total and let the customer try again. Until now that retry reused the original request and was refused, so the order could not be paid on this payment method at all. Your store now treats a changed total as a genuinely new payment. A customer pressing Pay twice by accident at the same total is still protected from being charged twice.

= 0.5.11 =
* The card fields now show their outline while they load, instead of leaving a blank gap. Your checkout also tells the shopper's browser, as early as it can, which servers the card fields are about to come from, so it can get those connections ready in advance rather than starting from scratch at the moment they are needed. Nothing about how a payment is taken has changed.

= 0.5.10 =
* Groundwork for automatic subscription renewals, which remain switched off. A renewal is a charge made while nobody is at the keyboard, and card networks treat that differently from a shopper pressing Pay. Your store now says so when it has the information to, which is what lets a bank waive the extra confirmation step it would otherwise ask a customer who is not there to answer it. Nothing changes for any payment a customer makes themselves.

= 0.5.9 =
* Fixed before it could reach a store: when an automatic subscription renewal was reported as failed, the order was marked failed without first checking whether the payment had in fact just succeeded. An order the customer had already paid for could have been left showing as failed. This cannot happen on any store today, because automatic renewals are switched off in this plugin. The fault was in the code that will handle them.

= 0.5.8 =
* A correction, on the safe side. Your store decides when a payment session has lapsed so it can start a fresh one. It was making that call up to a minute EARLY, and starting a fresh session replaces the one the card form on screen is already using. If a shopper paid in that minute, the money moved against the old session while the order recorded the new one, so the payment could not be matched to the order and the shopper could be charged again on retry. Your store now waits until the session has certainly lapsed before replacing it.
* If checking for updates fails, the plugin no longer keeps reporting that failure for half an hour after it has been fixed. Reinstalling or updating the plugin now clears the stored result, so a store owner who follows the advice in the message sees the real outcome straight away instead of the old one.

= 0.5.7 =
* Orders now record whether the shopper's bank asked them to confirm the payment, and what the bank answered. This is what proves a payment was covered by that extra check if a customer disputes it later.

= 0.5.6 =
* When this plugin cannot check for updates, it now says why in your store's logs. Previously five different problems, including a plugin too old to trust the current update signature, all failed the same way: silently, leaving the store looking up to date while it quietly stopped receiving fixes.

= 0.5.5 =
* The plugin now trusts a new key for verifying its own updates. No action is needed: every update it accepts is still signed and checked before it installs.

= 0.5.4 =
* A refund the payment processor cancels before it goes through is no longer recorded as a completed refund. Previously the order was marked refunded although the customer's card was never credited, and nothing later corrected it.

= 0.5.2 =
* Chargebacks now appear on the order. When a customer disputes a payment with their bank, the order gets a note saying so, and another when the dispute is resolved either way. Previously a chargeback left no trace anywhere in WooCommerce, so an order stayed looking paid with nothing to say the money had been challenged or taken back. The order is deliberately not changed in any other way: the amount taken back is not always the order total, so reconcile against your Von Payments dashboard.

= 0.5.1 =
* Fixed before this ever reached a store: a payment that a bank had only reserved, and not actually taken, could be read as a completed payment. An order would have been marked paid against money the store never received. It is now refused, and the shopper is told their card was not charged. This could not happen on any store today, because the plugin never asks for a reserved payment, but the fault was in the code that would have had to catch it.

= 0.5.0 =
The first release.

Everything below describes what this version does, rather than what changed,
because there is no earlier version anyone could have installed.

* Take card payments on your own checkout. The shopper types their card into a field Von Payments serves on your page, so the card number never reaches your server and your store stays in the lightest PCI category.
* Works on both checkouts. The block checkout and the classic checkout show the same card field and share the same settings.
* Cards that need bank verification go through. Where a shopper's bank asks them to confirm the payment, they are sent to their bank, approve it, and come back to their order. Most cards issued in Europe ask for this.
* Customers can save a card. A signed-in customer sees a tick box, never pre-ticked, and guests are never offered it. A card they did not agree to save is removed rather than left behind.
* Your orders say which card paid. The brand and last four digits appear on the order, the confirmation page, and the emails.
* Refunds from the order screen, in full or in part, and a refund you issue from the Von Payments dashboard appears on the order too.
* A payment can always be matched to an order. The order is created before the card is charged, so there is no moment where money has moved and nothing records it.
* Three independent safety nets finish an order whose payment confirmation does not arrive first time, and payments that match no order at all are counted and shown in your admin rather than only written to a log.
* A payment that was only reserved and not taken is refused rather than treated as complete, so an order is never marked paid against money the store has not received.
* A cancelled order cannot be reopened and marked paid by a late confirmation.
* Test mode is on when you install, so nothing is charged until you turn it off.
* Keys are checked when you save them. A key pasted into the wrong field is refused rather than stored, and if Von Payments rejects your keys the payment method comes off your checkout instead of asking shoppers for a card the store cannot charge.
* Updates are verified before they are installed. Each release is signed, and the download is checked against a fingerprint inside that signature, so a file that is not exactly the release we published is refused and your working copy is left alone.

Not in this version: wallet buttons such as Apple Pay and Google Pay, subscription
payments, and dispute notifications. Disputes are handled in your Von Payments
dashboard and do not appear on the WooCommerce order.
