vippsas / vipps-recurring-woocommerce Goto Github PK

View Code? Open in Web Editor NEW

6.0 9.0 4.0 3.95 MB

Vipps Recurring payments for WooCommerce

License: GNU Affero General Public License v3.0

CSS 0.38% PHP 98.76% JavaScript 0.86%

vipps woocommerce plugin

vipps-recurring-woocommerce's People

Contributors

Stargazers

Watchers

Forkers

brianweet danielcherubini rebekaburnett

vipps-recurring-woocommerce's Issues

Check if API details are valid when saving settings

Add a list of on-hold orders to the admin options page

Add a list of on-hold orders to the admin options page. This is useful to quickly tell what orders are on-hold, what agreement ID their subscription has and what charge ID they have. Perhaps also have a "fetch status" action on every single one

Not compatible with Wordpress 5.4.2

I use this plugin with woocommerce subscriptions, but when I activate the WS plugin, Vipps disappear. All the buttons and on the cart page. I get a message on the checkout page that no payment gateway is connected.
In woocommerce staus I see that Vipps is not tested with the Wordpress version I use 5.4.2

This is very frustrating, because I was recommended by Vipps to use these plugins together. And now nothing works.

Show latest API status in the "pending charges" table

Fails on manual renewals

I get the following error when trying to pay a manual renewal order:

PHP Fatal error: Uncaught Error: Call to a member function get_billing_period() on null in xxxx/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php:581
Stack trace:
#0 xxxx/wp-content/plugins/woocommerce/includes/class-wc-checkout.php(928): WC_Gateway_Vipps_Recurring->process_payment(5)
#1 xxxx/wp-content/plugins/woocommerce/includes/class-wc-checkout.php(1131): WC_Checkout->process_order_payment(5, 'vipps_recurring')
#2 xxxx/wp-content/plugins/woocommerce/includes/class-wc-ajax.php(462): WC_Checkout->process_checkout()
#3 xxxx/wp-includes/class-wp-hook.php(288): WC_AJAX::checkout('')
#4 xxxx/wp-includes/class-wp-hook.php(312): WP_Hook->apply_filters('', Array)
#5 xxxx/wp-includes/plugin.php(478): WP_Hook->do_action(Array)
#6 xxxx/wp-content/plugins/woocommerce/includes/class-wc-ajax. in xxxx/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php on line 581

Process_payment should probably check if wcs_order_contains_renewal and then get wcs_get_subscriptions_for_renewal_order if it contains a renewal.

Billing period

If you have a subscription that is charged every 2nd week or every 3rd month, it shows up in the vipps app as charged every week or every month. It seems IntervalCount is set to 1. Should it no be fetched from get_billing_interval?

Add settings for how many charges to check at once, and what sort order to use

There should be a setting that allows you to write your own number of charges to check at once. Should default to 10, and have an upper limit of 100.

Additionally there should be a setting to choose sort order of the checked orders. For example, oldest first, newest first and random. Default should be random.

This is a big issue for webshops that use synchronized payments as the same 8 random orders may be checked every time.

Support for All Products for Woocommerce Subscriptions

https://woocommerce.com/document/all-products-for-woocommerce-subscriptions/

It would seem that this payment option doesn't work for one of the official woocommerce subscription plugins. This plugin enables products to be added to subscription plans easier than doing variable subscriptions. Attached is an example of one of our products.

When taking this product through to the checkout, it would seem that this payment option ignores it, probably because it is a "simple-product" and not a "subscription" type product, either simple or variable...

We need to use this method for ease of use, and easy price calculations.. since we have a bot that changes the prices on the website..

Here's how it looks during the checkout

If there's anymore info you need please let me know.

We're editing an agreement after it has been cancelled

Steps to reproduce:

Checkout with Vipps recurring payments
Cancel on the landing page
The error should now be in the Vipps recurring payments error log if logs are enabled in the plugin settings

Error:

HTTP Response Error (400): status: Cannot modify an agreement which is not active.
(recurring/v2/agreements/agr_abc123) with request body: {"status":"STOPPED"}. The response was: [{"field":"status","message":"Cannot modify an agreement which is not active.","code":"recurring.core.agreement.status.invalid","contextId":"678e4f9f-e768-43b3-a52f-151ad12bea72"}]

This means we're trying to stop an agreement which is already stopped. It looks like we're not checking the current status of the agreement before cancelling, here:

vipps-recurring-woocommerce/includes/class-wc-gateway-vipps-recurring.php

Line 720 in d381a38

public function cancel_subscription( $subscription ) {

Add an option for what status a pending charge should have

When renewals happen there's a 2 day wait for orders to transition from on-hold to processing, this causes issues for access plugins like Memberships and for CRM system implementations.

It might be better to have the default as "trust the user to have paid" until proven otherwise mindset. As in, keep the transation on processing until the charge has actually failed. If it succeeds we do nothing except the usual adding of a note etc.

Patch agreement on subscription product price changes when an individual subscription is updated

WooCommerce does not update subscription prices automatically, retroactively. This makes it hard to even do something like this automatically as all the methods to update the price are either fully manual by doing it to each subscription separately or done through the database, where our code will not have any way of knowing about the change at all. This makes it extremely hard to do.

We'd most likely have to schedule a cron job here in order to do this in mass as it's a request per agreement and there could be a whole lot of requests. I'm not sure if this is the right solution and we need to think about if this is even possible in a reliable and good way at all. The main issue is how such a price update is even triggered in Woo.

If an automated task updates it through PHP in the same way you do it in the UI we could easily just schedule a cron (and pray people configure a proper cron). This is not the responsibility of a single payment gateway, though. We should only make sure this happens when a subscription is touched.

Race condition when paying for an order

It is technically possible to sign a payment agreement and then create yet another payment agreement on the same order.

If this happens the latest order takes precedence and when it times out the order will be marked as cancelled in Woo. We need to somehow stop this scenario from happening

Physical product with discount charges full price when manually captured

Physical product with discount charges full price when manually captured:

This could possibly affect renewals where a discount is applied too

Getting this error thrown out every minute. Any ideas on how to solve this?

Stack trace:
#0 /public_html/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-vipps-recurring-api.php(437): WC_Vipps_Recurring_Api->handle_http_response(Array, '{"status":"STOP...', 'recurring/v2/ag...', '')
#1 /public_html/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-vipps-recurring-api.php(221): WC_Vipps_Recurring_Api->http_call('recurring/v2/ag...', 'PATCH', Array, Array)
#2 /public_html/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-gateway-vipps-recurring.php(1232): WC_Vipps_Recurring_Api->cancel_agreement('agr_2sA22Px')
#3 /public_html/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/woo-vipps-recurring in /public_html/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-vipps-recurring-api.php on line 533

Edge case: "pending-cancel" will stay as "pending-cancel" even if a charge fails

When a charge transitions from the "DUE" status into a "FAILED" state we need to cancel a subscription if the current status of the subscription is "pending-cancel".

Tests: We should add phpunit tests to minimize errors

We can do much of the same as Stripe do with their payment gateway, especially the renewal/recurring tests.

https://github.com/woocommerce/woocommerce-gateway-stripe/blob/master/tests/phpunit

A few bugs regarding Vipps' new retry logic

It is now possible for a charge to move from FAILED to CHARGED, currently this leaves the order as "failed" in Woo because we do not check charges after they have been registered as FAILED.

There are a few ways we can fix this, but at the moment I think the best way to do this is to set a flag on failed orders which will tick down and retry at least 5 times. Afterwards it should remove the flag and consider this charge as actually failed.

UPDATE: The above "bug" is apparently not intended behaviour in Vipps as it breaks state management of a charge in this plugin and probably in a lot of other implementations. It should hopefully be fixed soon.

Another case I have seen is the confusing case in which an agreement can be PENDING when initialCharge has failed, thus the plugin will try to charge it one more time before marking the agreement as FAILED. This could be fixed by simply not adding the note for "pending charge created" if the charge is immediately marked as FAILED

Missing callback functionality

Hi,

I could not find a callback field in the https://vippsas.github.io/vipps-recurring-api/shins/index.html?http#create-a-new-agreement--to-be-confirmed-in-vipps for how to know when an agreement has been confirmed.

This would be preferred in front of calling your api regularly as we never know when a subscription has been confirmed.

Fatal error på noe som omhandler prevent_backwards_transition_on_completed_order :-(

Hei,
Har benyttet Vipps i WooCommerce i noen år nå, og har også knyttet Vipps Faste Betalinger uten problemer. Men, den siste tiden har vi lagt merke til at denne feilen dukket opp når vi forsøker å betale en subscription med Vipps Faste Betalinger:

Fatal error: Uncaught TypeError: Return value of WC_Gateway_Vipps_Recurring::prevent_backwards_transition_on_completed_order() must be of the type string, null returned in /home/<brukernavn>/public_html/< nettside >.no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-gateway-vipps-recurring.php:2031 Stack trace: #0 /home/<brukernavn>/public_html/<nettside>/wp-includes/class-wp-hook.php(307): WC_Gateway_Vipps_Recurring->prevent_backwards_transition_on_completed_order(NULL, 12001, Object(Automattic\WooCommerce\Admin\Overrides\Order)) #1 /home/<brukernavn>/public_html/<nettside>/wp-includes/plugin.php(189): WP_Hook->apply_filters(NULL, Array) #2 /home/<brukernavn>/public_html/<nettside>/wp-content/plugins/woocommerce/includes/class-wc-order.php(119): apply_filters('woocommerce_pay...', 'processing', 12001, Object(Automattic\WooCommerce\Admin\Overrides\Order)) #3 /home/<brukernavn>/public_html/<nettside>.no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-gateway-vipps-recurring.php(666): WC_Order in /home/<brukernavn>/public_html/<nettside>.no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/wc-gateway-vipps-recurring.php on line 2031

Kan ikke helt se hva som har endret seg den siste tiden eller hvorfor dette skal dukke opp. Kanskje det er en konflikt med en annen plugin, eller kanskje det er noen customisations vi har gjort som ødelegger for Vipps Faste Betalinger?

Hvor kan vi finne ut av hva som er årsaken uten å måtte "skru fra hverandre" hele nettsiden?

Fantastisk om dere kan bistå slik at vi kan nøste opp i dette. For øyeblikket klarer vi oss fint med Stripe, men vi vil veldig gjerne kunne tilby Vipps Faste Betalinger som et betalingsalternativ til våre kunder.

We should edit an agreement's productDescription when it's suspended and reactivated

We should edit an agreement's productDescription when it's suspended and reactivated.

When suspended we should add text saying when it will end so it's not confusing for the user in the Vipps app. The reverse applies to when a subscription is reactivated.

This should match the recommendations here: https://github.com/vippsas/vipps-recurring-api/blob/master/vipps-recurring-api.md#pause-an-agreement

Error on initialization

Hi, getting the following error in sytem log when going to checkout with a subscription product and payment method falls back to another provider.

2020-09-07T11:04:52+00:00 CRITICAL Uncaught Error: Call to undefined function array_key_last() in /home/username/www/no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php:876
Stack trace:
#0 /home/username/www/no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php(847): WC_Gateway_Vipps_Recurring->capture_payment(Object(Automattic\WooCommerce\Admin\Overrides\Order))
#1 /home/username/www/no/wp-includes/class-wp-hook.php(289): WC_Gateway_Vipps_Recurring->maybe_capture_payment(21429)
#2 /home/username/www/no/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array)
#3 /home/username/www/no/wp-includes/plugin.php(478): WP_Hook->do_action(Array)
#4 /home/username/www/no/wp-content/plugins/woocommerce/includes/class-wc-order.php(363): do_action('woocommerce_ord...', 21429, Object(Automattic\WooCommerce\Admin\Overrides\Order))
#5 /home/username/www/no/wp-con in /home/username/www/no/wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php on line 876

WC Version: 4.4.1
REST API Version: ✔ 1.0.15
WC Blocks Version: ✔ 3.1.0
Action Scheduler Version: ✔ 3.1.6
WC Admin Version: ✔ 1.4.0
Log Directory Writable: ✔
WP Version: 5.5.1
WP Multisite: –
WP Memory Limit: 256 MB
WP Debug Mode: –
WP Cron: ✔
Language: nb_NO
External object cache: –
Vipps faste betalinger for WooCommerce: av Everyday AS – 1.4.0
Betal med Vipps for WooCommerce: av WP Hosting – 1.4.11

Wrong handling of payment when user agrees to be notified before payment in the app

This is a copy of this issue:

vippsas/vipps-recurring-api#86

Possible temporary failure edge case with no automatic recovery

I noticed an order that had the following postmeta:

_vipps_recurring_captured: 1

and

_vipps_recurring_pending_charge: 1
_vipps_recurring_locked_for_update: 1

This means the charge was captured, but it failed before it was able to set pending_charge to 0 and update the order status. Perhaps a temporary failure with a certain API request?

This put the order in a state where it was not automatically recoverable and manual intervention was needed.

Truncate product fields

Failing to initialise payment.
Could this be increased? Or truncated by the plugin?
Product name and description (and others that might have issues?)

2020-09-07T14:55:10+00:00 DEBUG 
==== Vipps Recurring Version: 1.4.1 ====
==== Start Log ====
[21439] Error in process_payment: initialCharge.description: size must be between 0 and 45
productName: size must be between 0 and 45

Uncaught TypeError triggers fatal error in PHP 8.0

Line 1104 in wc-gateway-vipps-recurring.php tends to produce an uncaught TypeError when $agreement_id is a string. This triggers a mere warning in PHP 7.4—but a fatal error in PHP 8.0, causing the script to abort. See also: PHP Manual → Appendices → Migrating from PHP 7.4.x to PHP 8.0.x → Backward Incompatible Changes.

WooCommerce Subscriptions API v1

Hi, Im not able to parse payment_details->post_meta->_agreement_id via WooCommerce Subscriptions API v1.

The reason is most likely that there are no filter for 'woocommerce_subscription_payment_meta' in order to register payment_details->post_meta.

link for docs: here

Make sure charges marked as failed disappear from the charges tool

Abort in Vipps returns incorrectly

Hi,

We have an installation for a client using Vipps & Vipps recurring (https://kingsvenner.dev.webcore.no). If a user klicks on cancel in Vipps (https://api.vipps.no/vippsgateway?v=2&token=.....) - before entering phone-number - control is returned to "Thank you for your order" page and an order is created. In settings for vipps recurring we have set "Cancelled order redirect page" to the page responsible for handling this. (https://kingsvenner.dev.webcore.no/avlyst-vippsbetaling/).

Are we doing something obviously wrong or is this a known issue?

WP 5.7.2
Woo: 5.4.1
Woo subscriptions: 3.0.4
Vipps recurring: 1.8.0

Implement charge failure reasons in the UI

Vipps recently added charge failure reasons to the API:

https://vipps.no/developers-documentation/recurring/documentation/#charge-failure-reasons

We should add this to our UI as a separate table to the pending charges

When an order state for an uncaptured charge is changed to processing or completed we should capture the charge

When an order state for an uncaptured charge is changed to processing or completed we should capture the charge.

Order of events

If you cancel on the Vipps page after checkout, you get redirected to the order received page, which might be confusing for customers. It also triggers the woocommerce_thankyou hooks, and writes a message on the order that the initial payment (in case of digital subscription) is charged, when in fact it's not. Would it not be better to redirect back the checkout page if you cancel on the Vipps page?

Find out why we hit the rate-limits

No longer attempt to cancel charges that are already cancelled

Create more helper functions to aid WC < 3.0 compatibility

Currently we do a lot of calls to WC_Vipps_Recurring_Helper::is_wc_lt() for the same action like setting or getting a transaction id from an order, getting order or subscription id, getting a payment method or reducing stock. We can create helper functions for these so that we don't repeat the same code multiple times.

How can we force WooCommerce Subscriptions to retry failed payments if the retry system is enabled?

Currently it seems like the payments are not retried if they fail through an automatic payment. But should they not be?

https://docs.woocommerce.com/document/subscriptions/develop/failed-payment-retry/

WCS_Retry_Manager::maybe_apply_retry_rule seems to not be called, or return early in the first check in the function judging from my manual tests. This could be a non issue because I'm manually trying renewals, but the check for !self::is_scheduled_payment_attempt() is a bit suspicious to me.

I've seen automatic retries not be attempted on automatic payments for customers previously, but maybe these were manually created? I will have to ask.

Transaction ID: Which format should we use for the transaction id in WooCommerce?

Currently we use the charge id in the format from the Vipps API, however the eCommerce Vipps plugin seems to use the charge id with UL instead of _. Should we switch?

We use: chr_abc123
They use: chrULabc123

The transactionId can change in the API and is not recommended for use (a refund has a different transactionId than an initialCharge)

PHP error when checking pending orders

When force checking pending orders I get the following PHP notice:

file: "wp-content/plugins/vipps-recurring-payments-gateway-for-woocommerce/includes/class-wc-gateway-vipps-recurring.php"
line: 414
message: "Trying to access array offset on value of type bool"
stack: Array(4)
0: "WC_Gateway_Vipps_Recurring->check_charge_status()"
1: "WC_Vipps_Recurring->check_order_statuses()"
2: "WC_Vipps_Recurring->wp_ajax_vipps_recurring_force_check_charge_statuses()"
3: "do_action('wp_ajax_vipps_recurring_force_check_charge_statuses')"

Vipps Checkout - not showing recurring amount

When proceeding to checkout for a simple subscription service (donations), the Vipps Checkout page is for a single product (one time fee) and the recurring amount is not registered.

Direct capture

Should there not be an option to capture charge instantly, f. ex. for subscriptions that include both virtual access and physical product?

Ability to choose what field to source product description from

Add the ability to choose where the product description for use on an agreement in the app should come from, it should be one of the following:

Product title
Product short description
Custom field

The default should be product title to keep backwards compatibility.

Edge case when customer closes their browser before redirect back to merchant

There's an edge case where a payment does not get completed when a customer manages to close their browser tab before redirection back from Vipps.

There is currently a way to force check the status of an order and a user can do that themselves by going to "My account" then "Orders" and "View" on a single order. It will then force check if the order has been completed.

However, this is not enough as it is not an obvious thing to do for your average customer. I think the solution should be:

Use Scheduled Actions to check charges that are in the PENDING state. This way it requires no user action or administrative action. If used with the new WP cron system where it performs an ajax request instead of putting load on the user it will also not cause longer load times

This solution could be extremely simple and just a matter of adding this case to the existing cron for checking renewals

Add additional sorting in our tables

For example the ability to sort by failure reason in "failed charges".

We're not currently able to do this until we figure out how to sort by meta values. The current methods don't seem to work, maybe newer WooCommerce versions have changed it?

Another solution could be to call wp_get_posts instead of wc_get_posts directly, but this could be a pain.

Charges can fail on initial charge when a card is empty or does not have enough coverage

In a case like this our wp-cron would no longer retry as we consider a FAILED state the end state of an order. It's important for us to have an end state so we do bottleneck the wp-cron queue with too many unecessary checks.

That does however create a problem for us as we can't force a re-check in any 'good' way. We could do it on the redirect back from Vipps, but a user could theoretically close their browser before they're redirected. This means we have to solve it with the cron.

One solution that immediately comes to mind is to avoid marking an order as failed for a certain time interval directly after it's created. Say we avoid marking it as failed for 30 minutes, and after that we assume it failed if the status is still failed. With this solution it would re-check upon redirection, as well as re-check using the cron.

Sidenote: In my humble opinion I would prefer it if a charge could never have a status of FAILED unless it's the definitive end state of the charge. It should never be able to move from FAILED to any other state. A charge with a state of FAILED should be completely immutable.

Switching Subscriptions Does Not Update Recurring Cost

WooCommerce Subscriptions allows switching between subscription variations and grouped subscriptions. However, Vipps Recurring Payments for WooCommerce does not handle this use case correctly, as the new subscription maintains the old recurring cost. The upfront cost—prorated or not—calculates as it should. The problem seems to emerge from how process_payment defines $agreement_total, which translates to the recurring cost in the payment agreement: its value is derived from the order total of the related subscription—and this happens before WooCommerce Subscriptions performs recalculation. The problem is an insidious one, since everything appears normal on the WooCommerce front end, while the actual payment agreement does not concur.

Ability to export failed or pending charges as a CSV

Admin JavaScript asset not enqueud on WP 4.9

The script at assets/js/vipps-recurring-admin.js does not appear to be enqueued on WP 4.9, but is on WP 5.0+

Variable subscriptions are not supported

We should enable support for these - will require some testing.

Force check all pending transactions now button in ACP

A cron-job can be very slow if you have a bunch of orders to process. Currently the cron job only processes 5 orders every 5 minutes. This is slow, but it's done this way to not inconvenience users too much. A big load time = lost customers.

However, if you have a huge amount of orders it might be beneficial for us to add a "force check all pending Vipps transactions" in the admin control panel. This would run an ajax request to an endpoint where we would force check the status of all pending Vipps orders.

Error if "Custom description" is blank when "Description source" is set to "Custom" on a product

This bug makes it impossible to purchase the product in question.

Conflict with Klarna checkout

https://wordpress.org/support/topic/vipps-recurring-not-working-with-klarna-checkout/