* handle plain options passed to registerPaymentMethod:
- no need for a callback dance
- support the previous API: if a function is passed, call it as before
* update Stripe for new registerPaymentMethod interface
* update docs & all built-in payment methods to simpler API
* handle plain options arg to registerExpressPaymentMethod:
- add legacy fallback if passed a function
- update stripe express payment method
- update docs
- remove unused `assertValidPaymentMethodCreator` util
* use correct case for `JavaScript`
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* typedefs for payment registration options + tidies for regular methods
* typedef express payment options arg & tidy stripe/payment-request:
- use camelCase for config instance (not a constructor/type)
* mention typedefs in payment method dev docs
* use @wordpress/deprecated to warn if callback passed to payment register
* update unit tests for new payment method API
Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
* stub out COD payment method for checkout block
* consistently use sentence case for (default) payment tab labels
* expose COD `enable_for_virtual` option to client
* correct docblock return value comment Stripe::get_inline_cc_form()
* allow merchant to disable COD payment for virtual/downloadable orders
* tweak canMakePayment dev docs - add cart-dependent example use case
* only allow (show) COD if initially-selected shipping method(s) allow
* tweak `canMakePayment` payment extension API docs
* use $VID:$ substitution for `@since` version in new payment methods
* use FILTER_VALIDATE_BOOLEAN for payment method boolean options
* use more semantic `some` when hunting for COD-unsupported shipping
* clarify `canMakePayment` API docs
* re-select payment method if selected method disappears (e.g. COD) +
+ factor out early return into separate if at top for clarity
* remove obsolete useStoreOrder hook and implementation.
This hook was actually never completed and was only implemented in the `usePaymentMethodInterface` hook/api. The original purpose was to expose order details to registered payment methods, but that is now exposed via checkout state event emitters so it’s no longer needed.
OrderId is exposed via the `CheckoutState` context provider.
* remove setBillingData from being exposed to payment methods directly
billingData is updated via event emitter callback responses (see payment method data context provider) and is not something that should be set directly via payment methods.
We want checkout to have control over how billing data is updated in the state.
* add documentation for checkotu flow and payment method integrations
* Update docs/block-client-apis/README.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* Update docs/block-client-apis/README.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* Update docs/block-client-apis/checkout/checkout-api.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* standardize around capitalized API
* Remove extra dash.
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* Update docs/block-client-apis/checkout/checkout-api.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* Update docs/block-client-apis/checkout/checkout-api.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* Update docs/block-client-apis/checkout/checkout-api.md
Co-Authored-By: Mike Jolley <mike.jolley@me.com>
* remove 1st person narrative
* various other grammar fixes
* add table of contents to docs
Co-authored-by: Mike Jolley <mike.jolley@me.com>
Rua Haszard
Darren Ethier
Mike Jolley