* enqueue order of payment gateways as script data
* use configured gateway order for payment method tabs
* clarify name of payment gateway sort order setting
* fix formatting
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* fix bug - express payment methods not working due to ordering logic:
- move ordering code to payment methods in usePaymentMethods hook;
- this only applies to standard (non express) payment methods
- also any code that uses payment methods will get them in correct order
* why did this formatting not happen pre-commit?
* move method ordering into refreshPaymentMethods to avoid infinite loop:
- pass keys of express payment methods so they work correctly (show up)
- refreshPaymentMethods dispatches availablePaymentMethods to redux
store; I suspect this was causing infinite loop as the callback
depends on registeredPaymentMethods
- handle case when a payment method is not in PAYMENT_GATEWAY_SORT_ORDER
- this happens with COD when dependent on shipping
* fix formatting
* use shallow equal to prevent refreshCanMakePayments infinite loop
* use native Set instead of lodash.union for unique gateway names
* code formatting
* check to ensure we register paymentGatewaySortOrder asset once only
* fix COD tab showing out of order if not available at page load:
- return ALL gateways in sort order array
- note this includes gateways that are not enabled by merchant
* reinstate return bool from usePaymentMethods hook (broken in refactor)
* add basic typedefs for payment methods hooks
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* allow payment methods to disable based on shipping or other factors:
- renamed 'initialized' array 'available' to match primary purpose of
`canMakePayment` api - whether payment method should be available
- trigger refresh of available payment methods when shopper chooses
different shipping method
- rename resolveCanMakePayments => refreshCanMakePayments
- tweaked some variable names and scope for clarity
- added comments to clarify things
Note this should not affect behaviour yet - no existing payment methods
use this new feature. COD payment method will need this - woocommerce/woocommerce-blocks#2831
* optimise refreshCanMakePayments:
- useShallowEqual to avoid unnecessary call when shipping methods have
not actually changed (but object value has)
* replace ("set") payment methods in store, was appending:
- payment methods may come and go depending on cart/checkout state
- the previous SET action appended provided payment methods to the
collection
- this prevents dynamic payment methods e.g. COD from being able to hide
i.e. disable
* cache test payment request to avoid unnecessary stripe API calls:
- in the canMakePayment callback there's a test payment to determine if
chrome pay/apple pay is set up and available
- canMakePayment is now called multiple times as checkout state changes
- now the results of the test payment are stored in variable, and
returned on subsequent calls
* set init flag to avoid additional attempts to init stripe API:
+ tweak naming of init flag
* Refactor usePaymentMethodRegistration so initialisation happens at same point as dispatch
* Update NoPaymentMethods conditonal
* Suggested changes to payment init
* Handle errors when loading payment methods
* Use an error boundary
* Fix missing initial state in block error boundary
* Cleanup
* Only show internal user messages if it's admin or in editor
* Fixes
* Add friendly error message
* remove stripe.js registration because it is lazy loaded via the library used.
* refactor payment method registration to preserve registration order.
* register payment method asset handles as dependency on editor script as well.
* use cart data to provide country and currency_code
* remove files that likely got added back in from a bad rebase.
* modify canMakePayment config property so it must be a function
* Feed cart data to registered payment methods `canMakePayment` function.
This can then be used by payment methods for determining whether to show the payment method or not.
* implement new canMakePayment signature for cheque
Now canMakePayment doesn’t need to be a promise (payment method registry will handle wrapping all values in a promise to treat them as promises.
* implement canMakePayment as a function
* Rename and move existing checkout provider to checkout-state provider.
This allows us to re-use the interface exposed on this provider for cart and checkout blocks.
* refactor checkout provider to implement the new checkout state provider.
* Add Cart provider and export
* fix type-defs
* fix editor context provider and ensure all `isEditor` checks come from this provider
* fix type definition
* implement cart provider
* Add saved-payment-method options handling and improve payment method registration initialization
* add server side exposure of saved customer payment methods
* fix reducer for express payment method state
* fix default for customerPaymentMethods
Rua Haszard
Mike Jolley
Albert Juhé Lluveras
Darren Ethier