woocommerce/plugins/woocommerce-blocks/assets/js/base/context/cart-checkout/payment-methods/payment-method-data-context.js

462 lines
13 KiB
JavaScript
Raw Normal View History

/**
* External dependencies
*/
import {
createContext,
useContext,
useState,
useReducer,
useCallback,
useEffect,
useRef,
useMemo,
} from '@wordpress/element';
import { getSetting } from '@woocommerce/settings';
import { useStoreNotices, useEmitResponse } from '@woocommerce/base-hooks';
import { useEditorContext } from '@woocommerce/base-context';
/**
* Internal dependencies
*/
import {
STATUS,
DEFAULT_PAYMENT_DATA,
DEFAULT_PAYMENT_METHOD_DATA,
} from './constants';
import reducer from './reducer';
import {
statusOnly,
error,
failed,
success,
setRegisteredPaymentMethods,
setRegisteredExpressPaymentMethods,
Allow shopper to save Stripe payment method in user account for subsequent purchases (https://github.com/woocommerce/woocommerce-blocks/pull/2453) * always default "save my card for next time" checkbox to unchecked: This is based on the previous checkout behaviour. I.e. the shopper has to actively opt-in to save their card. * Implement "save payment method for next purchase" in checkout: - send "save card" option using existing post key - wc-stripe-new-payment-method - comment out inappropriate use of "save" when using a saved card (tbc) * don't hard code the payment gateway name in 'save payment method' key * refactor "save payment info" checkbox so payment methods can opt-in: - Add options.allowSavePaymentToken to payment method registration / config. - Opt-in in Stripe CC, it allows saved cards. - Remove render of "save my card" checkbox from Stripe CC UI component. - Render "save my card" checkbox automatically in payment method tab (based on allowSavePaymentToken option). + todo/follow up comments * rejig "save my payment method" behaviour so it's generic: - Any payment method that supports "save" can opt-in: - options.allowSavePaymentToken = true/false - handle `wc-XXX-new-payment-method` key server side to persist - Add support in payment context/state reducer for storing checkbox state, expose value and action via context - Convert state flag to appropriate API key/value in payment processor - Remove previous stripe-specific implementation + bonus add comment to payment context about preserving state in PRISTINE action * rename payment method "allow save" option, more consistent with UI * remove last vestiges of gateway-specific "save card" impl: - No need to pass CheckboxControl to payment methods; checkbox is now handled automatically by checkout. - Remove shouldSavePayment prop passing through various layers of stripe payment processing code. (Now handled in context/processor.) * change new option property name and shape. Also adds validation. * update type-defs * use more reliable `activePaymentMethod` for saved payment method Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2020-05-12 15:12:28 +00:00
setShouldSavePaymentMethod,
} from './actions';
import {
usePaymentMethods,
useExpressPaymentMethods,
} from './use-payment-method-registration';
Sync shipping address with billing address when shipping address fields are disabled (https://github.com/woocommerce/woocommerce-blocks/pull/3358) * Correct docblock description * Sync shipping address changes with billing data * Update inline documentation * Revert address sync because it fails when shipping is disabled explicitely * Avoid loading shipping address from customer is shipping is disabled * Rather than update order from the wc/store/checkout request, update the customer object This is turn is synced to order, but also allows the cart calcultions to use the posted data. This means that taxes will be updated based on address data even if not displayed on the checkout. * Add action that combines billing and shipping updates * Add route for updating billing and shipping address * Sync billing data to server on change * Shared constants for billing data * Skip address update if missing country * Allow null values to skip formatting * Add billing to cart schema * Removed unwanted hooks from previous commit * Decoding is handled in useStoreCart * Remove hook * Make shipping context hold state * Make billing context hold state * Add address processors * Cart does not have billing * Update tests, remove some unrelated changes affecting the diff * Revert "Update inline documentation" This reverts commit 0393f49316de3152c6dcf6fda1192c06a74f1b55. * Make shippingRatesAreResolving conditonal based on API request * Shared address processor in cart and checkout * Rename REST endpoint * CustomerDataProvider and hook * Update shipping address type defs * Rename customer address endpoint, and remove update-shipping * Update tests * Fix tests by restoring country validation * typo * Update assets/js/base/hooks/cart/use-store-cart.js Co-authored-by: Darren Ethier <darren@roughsmootheng.in> * Simplify debounce and request handling * Remove state from address sync This will mean billing is "forgotten" if using the checbox, but this greatly simplifies logic. * Rename shipping rates loading to customer data loading * Sync based on useStoreCart data * Made cart API less strict on addresses * Fix useCheckoutAddress sync * Add note on currentShippingAsBilling * Use incoming isCart * Add more detailed inline comment for shippingAsBilling toggle event * Combine customer billing and shipping ref * Update address docblock * Error handling in pluckAddress * Fix cart response after rebase * Update customer tests * Update src/StoreApi/Routes/CartUpdateCustomer.php Co-authored-by: Darren Ethier <darren@roughsmootheng.in> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2020-11-20 15:13:35 +00:00
import { useCustomerDataContext } from '../customer';
import { useCheckoutContext } from '../checkout-state';
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
import { useShippingDataContext } from '../shipping';
import {
EMIT_TYPES,
emitterSubscribers,
emitEventWithAbort,
reducer as emitReducer,
} from './event-emit';
2020-07-30 10:57:22 +00:00
import { useValidationContext } from '../../shared/validation';
/**
* @typedef {import('@woocommerce/type-defs/contexts').PaymentMethodDataContext} PaymentMethodDataContext
* @typedef {import('@woocommerce/type-defs/contexts').PaymentStatusDispatch} PaymentStatusDispatch
* @typedef {import('@woocommerce/type-defs/contexts').PaymentStatusDispatchers} PaymentStatusDispatchers
* @typedef {import('@woocommerce/type-defs/billing').BillingData} BillingData
* @typedef {import('@woocommerce/type-defs/contexts').CustomerPaymentMethod} CustomerPaymentMethod
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
* @typedef {import('@woocommerce/type-defs/contexts').ShippingDataResponse} ShippingDataResponse
*/
const {
STARTED,
PROCESSING,
COMPLETE,
PRISTINE,
ERROR,
FAILED,
SUCCESS,
} = STATUS;
const PaymentMethodDataContext = createContext( DEFAULT_PAYMENT_METHOD_DATA );
/**
* @return {PaymentMethodDataContext} The data and functions exposed by the
* payment method context provider.
*/
export const usePaymentMethodDataContext = () => {
return useContext( PaymentMethodDataContext );
};
/**
* Gets the payment methods saved for the current user after filtering out
* disabled ones.
*
* @param {Object[]} availablePaymentMethods List of available payment methods.
* @return {Object} Object containing the payment methods saved for a specific
* user which are available.
*/
const getCustomerPaymentMethods = ( availablePaymentMethods = [] ) => {
const customerPaymentMethods = getSetting( 'customerPaymentMethods', {} );
const paymentMethodKeys = Object.keys( customerPaymentMethods );
if ( paymentMethodKeys.length === 0 ) {
return {};
}
const enabledCustomerPaymentMethods = {};
paymentMethodKeys.forEach( ( type ) => {
enabledCustomerPaymentMethods[ type ] = customerPaymentMethods[
type
].filter( ( paymentMethod ) => {
return Object.keys( availablePaymentMethods ).includes(
paymentMethod.method.gateway
);
} );
} );
return enabledCustomerPaymentMethods;
};
/**
* PaymentMethodDataProvider is automatically included in the
* CheckoutDataProvider.
*
* This provides the api interface (via the context hook) for payment method
* status and data.
*
* @param {Object} props Incoming props for provider
* @param {Object} props.children The wrapped components in this
* provider.
*/
export const PaymentMethodDataProvider = ( { children } ) => {
Sync shipping address with billing address when shipping address fields are disabled (https://github.com/woocommerce/woocommerce-blocks/pull/3358) * Correct docblock description * Sync shipping address changes with billing data * Update inline documentation * Revert address sync because it fails when shipping is disabled explicitely * Avoid loading shipping address from customer is shipping is disabled * Rather than update order from the wc/store/checkout request, update the customer object This is turn is synced to order, but also allows the cart calcultions to use the posted data. This means that taxes will be updated based on address data even if not displayed on the checkout. * Add action that combines billing and shipping updates * Add route for updating billing and shipping address * Sync billing data to server on change * Shared constants for billing data * Skip address update if missing country * Allow null values to skip formatting * Add billing to cart schema * Removed unwanted hooks from previous commit * Decoding is handled in useStoreCart * Remove hook * Make shipping context hold state * Make billing context hold state * Add address processors * Cart does not have billing * Update tests, remove some unrelated changes affecting the diff * Revert "Update inline documentation" This reverts commit 0393f49316de3152c6dcf6fda1192c06a74f1b55. * Make shippingRatesAreResolving conditonal based on API request * Shared address processor in cart and checkout * Rename REST endpoint * CustomerDataProvider and hook * Update shipping address type defs * Rename customer address endpoint, and remove update-shipping * Update tests * Fix tests by restoring country validation * typo * Update assets/js/base/hooks/cart/use-store-cart.js Co-authored-by: Darren Ethier <darren@roughsmootheng.in> * Simplify debounce and request handling * Remove state from address sync This will mean billing is "forgotten" if using the checbox, but this greatly simplifies logic. * Rename shipping rates loading to customer data loading * Sync based on useStoreCart data * Made cart API less strict on addresses * Fix useCheckoutAddress sync * Add note on currentShippingAsBilling * Use incoming isCart * Add more detailed inline comment for shippingAsBilling toggle event * Combine customer billing and shipping ref * Update address docblock * Error handling in pluckAddress * Fix cart response after rebase * Update customer tests * Update src/StoreApi/Routes/CartUpdateCustomer.php Co-authored-by: Darren Ethier <darren@roughsmootheng.in> Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2020-11-20 15:13:35 +00:00
const { setBillingData } = useCustomerDataContext();
const {
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
isProcessing: checkoutIsProcessing,
isIdle: checkoutIsIdle,
isCalculating: checkoutIsCalculating,
hasError: checkoutHasError,
} = useCheckoutContext();
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
const {
isSuccessResponse,
isErrorResponse,
isFailResponse,
noticeContexts,
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
} = useEmitResponse();
const [ activePaymentMethod, setActive ] = useState( '' );
const [ observers, subscriber ] = useReducer( emitReducer, {} );
const currentObservers = useRef( observers );
const { isEditor, previewData } = useEditorContext();
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
const [ paymentData, dispatch ] = useReducer(
reducer,
DEFAULT_PAYMENT_DATA
);
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
const setActivePaymentMethod = useCallback(
( paymentMethodSlug ) => {
setActive( paymentMethodSlug );
dispatch( statusOnly( PRISTINE ) );
},
[ setActive, dispatch ]
);
const paymentMethodsDispatcher = useCallback(
( paymentMethods ) => {
dispatch( setRegisteredPaymentMethods( paymentMethods ) );
},
[ dispatch ]
);
const expressPaymentMethodsDispatcher = useCallback(
( paymentMethods ) => {
dispatch( setRegisteredExpressPaymentMethods( paymentMethods ) );
},
[ dispatch ]
);
const paymentMethodsInitialized = usePaymentMethods(
paymentMethodsDispatcher
);
const expressPaymentMethodsInitialized = useExpressPaymentMethods(
expressPaymentMethodsDispatcher
);
const { setValidationErrors } = useValidationContext();
const { addErrorNotice, removeNotice } = useStoreNotices();
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
const { setShippingAddress } = useShippingDataContext();
Allow shopper to save Stripe payment method in user account for subsequent purchases (https://github.com/woocommerce/woocommerce-blocks/pull/2453) * always default "save my card for next time" checkbox to unchecked: This is based on the previous checkout behaviour. I.e. the shopper has to actively opt-in to save their card. * Implement "save payment method for next purchase" in checkout: - send "save card" option using existing post key - wc-stripe-new-payment-method - comment out inappropriate use of "save" when using a saved card (tbc) * don't hard code the payment gateway name in 'save payment method' key * refactor "save payment info" checkbox so payment methods can opt-in: - Add options.allowSavePaymentToken to payment method registration / config. - Opt-in in Stripe CC, it allows saved cards. - Remove render of "save my card" checkbox from Stripe CC UI component. - Render "save my card" checkbox automatically in payment method tab (based on allowSavePaymentToken option). + todo/follow up comments * rejig "save my payment method" behaviour so it's generic: - Any payment method that supports "save" can opt-in: - options.allowSavePaymentToken = true/false - handle `wc-XXX-new-payment-method` key server side to persist - Add support in payment context/state reducer for storing checkbox state, expose value and action via context - Convert state flag to appropriate API key/value in payment processor - Remove previous stripe-specific implementation + bonus add comment to payment context about preserving state in PRISTINE action * rename payment method "allow save" option, more consistent with UI * remove last vestiges of gateway-specific "save card" impl: - No need to pass CheckboxControl to payment methods; checkbox is now handled automatically by checkout. - Remove shouldSavePayment prop passing through various layers of stripe payment processing code. (Now handled in context/processor.) * change new option property name and shape. Also adds validation. * update type-defs * use more reliable `activePaymentMethod` for saved payment method Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2020-05-12 15:12:28 +00:00
const setShouldSavePayment = useCallback(
( shouldSave ) => {
dispatch( setShouldSavePaymentMethod( shouldSave ) );
},
[ dispatch ]
);
const customerPaymentMethods = useMemo( () => {
if ( isEditor && previewData.previewSavedPaymentMethods ) {
return previewData.previewSavedPaymentMethods;
}
if (
! paymentMethodsInitialized ||
paymentData.paymentMethods.length === 0
) {
return {};
}
return getCustomerPaymentMethods( paymentData.paymentMethods );
}, [
isEditor,
previewData.previewSavedPaymentMethods,
paymentMethodsInitialized,
paymentData.paymentMethods,
] );
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
const setExpressPaymentError = useCallback(
( message ) => {
if ( message ) {
addErrorNotice( message, {
id: 'wc-express-payment-error',
context: noticeContexts.EXPRESS_PAYMENTS,
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
} );
} else {
removeNotice(
'wc-express-payment-error',
noticeContexts.EXPRESS_PAYMENTS
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
);
}
},
[ addErrorNotice, noticeContexts.EXPRESS_PAYMENTS, removeNotice ]
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
);
// ensure observers are always current.
useEffect( () => {
currentObservers.current = observers;
}, [ observers ] );
const onPaymentProcessing = useMemo(
() => emitterSubscribers( subscriber ).onPaymentProcessing,
[ subscriber ]
);
const currentStatus = useMemo(
() => ( {
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
isPristine: paymentData.currentStatus === PRISTINE,
isStarted: paymentData.currentStatus === STARTED,
isProcessing: paymentData.currentStatus === PROCESSING,
isFinished: [ ERROR, FAILED, SUCCESS ].includes(
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
paymentData.currentStatus
),
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
hasError: paymentData.currentStatus === ERROR,
hasFailed: paymentData.currentStatus === FAILED,
isSuccessful: paymentData.currentStatus === SUCCESS,
} ),
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
[ paymentData.currentStatus ]
);
/**
* @type {PaymentStatusDispatch}
*/
const setPaymentStatus = useCallback(
() => ( {
started: () => dispatch( statusOnly( STARTED ) ),
processing: () => dispatch( statusOnly( PROCESSING ) ),
completed: () => dispatch( statusOnly( COMPLETE ) ),
/**
* @param {string} errorMessage An error message
*/
error: ( errorMessage ) => dispatch( error( errorMessage ) ),
/**
* @param {string} errorMessage An error message
* @param {Object} paymentMethodData Arbitrary payment method data to
* accompany the checkout submission.
* @param {BillingData|null} [billingData] The billing data accompanying the
* payment method.
*/
failed: ( errorMessage, paymentMethodData, billingData = null ) => {
if ( billingData ) {
setBillingData( billingData );
}
dispatch(
failed( {
errorMessage,
paymentMethodData,
} )
);
},
/**
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
* @param {Object} [paymentMethodData] Arbitrary payment method data to
* accompany the checkout.
* @param {BillingData|null} [billingData] The billing data accompanying the
* payment method.
* @param {ShippingDataResponse|null} [shippingData] The shipping data accompanying the
* payment method.
*/
Convert apple pay integration to payment request integration and finish implementation (https://github.com/woocommerce/woocommerce-blocks/pull/2127) * add logic allowing payment method to be overridden via payment data in request * hook in to trigger server side processing of stripe payment request * improvements to shipping data context - memoize event emitters - split up emitted events (reduces how often events trigger) - Include whether rate is being selected in exported data. * expose `isSelectingRate` value to payment method interface * fix typo in shipping emitters for emitter type * include setting of shipping data in payment method success status call - this also requires changing the nested order of providers in checkout provider * fix priority logic for event emitters. - lower priority is supposed to fire before higher priority. * normalize postal code for comparisons * move normalize functions into stripe-utils folder * refactor stripePromise so that it provides a specific instance to each payment method. This also provides it as a prop to the pm components. * renadme apple pay express to payment request express This adds full support for the stripe payment request api instead of just applePay (so GooglePay, MicrosoftPay and ApplePay are now supported). Also adds numerous fixes to internal logic. * add handling to skip core checkout validation logic if express payment method is handling payment Express payment methods have their own internal validation so this removes the need for checkout validating fields. This is also necessary because checkout validation breaks the flow when making a payment using express payment methods because of the order of the flow for these methods. * splitting out emmitter effects for checkout and improving logic Splitting up effects limits the potential for firing off emitters more than needed. * remove unnecessary ref definitions * fix on cancel action erroring for payment request modal * ensure unique stripe object for component and canPay * set default total label if one isn’t configured on the server * fix order of state changes * simplify condition * remove unnecessary dependency * normalize to uppercase too * simplify can make payment conditional * update comment blocks
2020-04-08 16:36:04 +00:00
success: (
paymentMethodData = {},
billingData = null,
shippingData = null
) => {
if ( billingData ) {
setBillingData( billingData );
}
Fix shipping rate and address handling in Stripe payment request payment method. (https://github.com/woocommerce/woocommerce-blocks/pull/2484) * fix dependencies * refactor stripe payment-request to extract things into smaller units - adds/fixes typedefs - fixes dependencies - improves logic. * implement memoizing for functions. * if same shipping address is selected, just call updateWith immediately * add separate handler for failed shipping rate retrieval * improve logic around shipping rate fail/success status * add notice suppression logic to store notices. - this is implemented in checkout processor to suppress notices when express payment methods are active. * add error detection for shipping address errors and update the shipping status accordingly * update type-def * set billingData before shippingData This is needed because of the shipping data and billing data sync logic in use-checkout-address. * have to tighten dependencies to prevent unnecessary firing With us now adding error status setters for shippping, the potential for the shipping status changes to trigger the effect went up. So tightening the dependencies to only the stati we care about prevent unnecessary effect calls. * refactor event handlers to be named and remove all listeners. This is an undocumented api on the stripe `paymentRequest.on` return value, but I’m trusting it will be relatively stable for this api. The need for this is caused by the fact that without it, the listeners are re-registered on the paymentRequest event everytime the paymentRequest modal is closed and reopened. * fix typo in doc block
2020-05-14 23:55:22 +00:00
if ( shippingData !== null && shippingData?.address ) {
setShippingAddress( shippingData.address );
}
dispatch(
success( {
paymentMethodData,
} )
);
},
} ),
[ dispatch, setBillingData, setShippingAddress ]
);
// flip payment to processing if checkout processing is complete, there are
// no errors, and payment status is started.
useEffect( () => {
if (
checkoutIsProcessing &&
! checkoutHasError &&
! checkoutIsCalculating &&
! currentStatus.isFinished
) {
setPaymentStatus().processing();
}
}, [
checkoutIsProcessing,
checkoutHasError,
checkoutIsCalculating,
currentStatus.isFinished,
setPaymentStatus,
] );
// When checkout is returned to idle, set payment status to pristine
// but only if payment status is already not finished.
useEffect( () => {
if ( checkoutIsIdle && ! currentStatus.isSuccessful ) {
dispatch( statusOnly( PRISTINE ) );
}
}, [ checkoutIsIdle, currentStatus.isSuccessful ] );
// if checkout has an error and payment is not being made with a saved token
// and payment status is success, then let's sync payment status back to
// pristine.
useEffect( () => {
if (
checkoutHasError &&
currentStatus.isSuccessful &&
! paymentData.hasSavedToken
) {
dispatch( statusOnly( PRISTINE ) );
}
}, [
checkoutHasError,
currentStatus.isSuccessful,
paymentData.hasSavedToken,
] );
// Set active (selected) payment method as needed.
useEffect( () => {
const paymentMethodKeys = Object.keys( paymentData.paymentMethods );
const allPaymentMethodKeys = [
...paymentMethodKeys,
...Object.keys( paymentData.expressPaymentMethods ),
];
if ( ! paymentMethodsInitialized || ! paymentMethodKeys.length ) {
return;
}
setActive( ( currentActivePaymentMethod ) => {
// If there's no active payment method, or the active payment method has
// been removed (e.g. COD vs shipping methods), set one as active.
// Note: It's possible that the active payment method might be an
// express payment method. So registered express payment methods are
// included in the check here.
if (
! currentActivePaymentMethod ||
! allPaymentMethodKeys.includes( currentActivePaymentMethod )
) {
dispatch( statusOnly( PRISTINE ) );
return Object.keys( paymentData.paymentMethods )[ 0 ];
}
return currentActivePaymentMethod;
} );
}, [
paymentMethodsInitialized,
paymentData.paymentMethods,
paymentData.expressPaymentMethods,
setActive,
] );
// emit events.
useEffect( () => {
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
// Note: the nature of this event emitter is that it will bail on any
// observer that returns a response that !== true. However, this still
// allows for other observers that return true for continuing through
// to the next observer (or bailing if there's a problem).
if ( currentStatus.isProcessing ) {
removeNotice( 'wc-payment-error', noticeContexts.PAYMENTS );
emitEventWithAbort(
currentObservers.current,
EMIT_TYPES.PAYMENT_PROCESSING,
{}
).then( ( response ) => {
if ( isSuccessResponse( response ) ) {
setPaymentStatus().success(
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
response?.meta?.paymentMethodData,
response?.meta?.billingData,
response?.meta?.shippingData
);
} else if ( isFailResponse( response ) ) {
if ( response.message && response.message.length ) {
addErrorNotice( response.message, {
id: 'wc-payment-error',
isDismissible: false,
context:
response?.messageContext ||
noticeContexts.PAYMENTS,
} );
}
setPaymentStatus().failed(
response?.message,
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
response?.meta?.paymentMethodData,
response?.meta?.billingData
);
} else if ( isErrorResponse( response ) ) {
if ( response.message && response.message.length ) {
addErrorNotice( response.message, {
id: 'wc-payment-error',
isDismissible: false,
context:
response?.messageContext ||
noticeContexts.PAYMENTS,
} );
}
Refactor checkout status and event emitters to support stripe intents and more complex payment methods. (https://github.com/woocommerce/woocommerce-blocks/pull/2189) * initial mapping out of stripe payment intents * rename checkout processing statuses to be clearer * Add new status and refactor checkout complete behaviour. * Make sure payment result data is included in checkout processing response * add payment intent handling Still testing * make sure promise is returned * include site url with endpoint * modify setComplete status to optionally receive redirectUrl for changing in state at the same time as setting status * fix typo in property retrieval * add error handling for after checkout processing event * add notices area for payment methods * implement error handling for stripe intents * hook into stripe error processing and include error in payment response * clear notices so they don’t show in block and merge payment details * add notice handling to payment context * modify error processing in checkout processor * handle errors with fallback in checkout state context * hook into after processing for stripe cc error handling * set checkout to idle status if before processing emitters result in error * Add emit response type-defs and normalize expectations for observer responses * improve doc block * switch checkoutIsComplete check to checkoutAfterProcessing for payment complete status change * remove unneeded event emitters and consolidate some logic * fix idle status set logic
2020-04-14 16:52:23 +00:00
setPaymentStatus().error( response.message );
setValidationErrors( response?.validationErrors );
} else {
// otherwise there are no payment methods doing anything so
// just consider success
setPaymentStatus().success();
}
} );
}
}, [
currentStatus.isProcessing,
setValidationErrors,
setPaymentStatus,
removeNotice,
noticeContexts.PAYMENTS,
isSuccessResponse,
isFailResponse,
isErrorResponse,
addErrorNotice,
] );
Implement Stripe CC and Stripe ApplePay payment methods (https://github.com/woocommerce/woocommerce-blocks/pull/1983) * Server side changes for payment method integrations Including adding a stripe class temporarily * update needed npm packages (and add some types) * updates to contexts * remove stepContent from payment config for payment methods * update payment method interface and typedefs Exposing a components property to pass along components that payment methods can use (so we keep styles consistent for them) * add apple pay and stripe cc integration and remove paypal * remove save payment checkbox from checkout block It is handled by payment methods. * Include an id prop for tabs * fix activePaymentMethod pass through on rendered payment method element also adds an id for the rendered tab * add styles for payment method fields If payment methods use these classes for their fields then the styles will get applied. It _could_ allow for consistent styling, we may have to provide design documentation for this? These are styles in cases where payment methods have to use elements provided by the gateway (eg. Stripe elements). In future iterations we could look at providing components to payment methods to use (if they aren’t restricted by the gateway). * fix rebase conflict * do a test payment request for applePay to determine if the current browser supports it * don’t console.error for stripe loading. * Fix placeholder errors in the editor * improve styling and add missing validation for inline card element * update pacakge-lock * rename payment-methods-demo folder to payment-methods-extension * expose checkbox control on payment method interface * export payment-methods-extension to it’s own asset build This allows us to more accurately demonstrate how payment extensions would hook in to the blocks. * don’t enqueue a style that doesn’t exist * add full stop to comments and remove obsolete comment blcok * fix spacing * switch `activeContent` to `content` for payment method registration config
2020-03-30 12:07:49 +00:00
/**
* @type {PaymentMethodDataContext}
*/
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
const paymentContextData = {
setPaymentStatus,
currentStatus,
paymentStatuses: STATUS,
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
paymentMethodData: paymentData.paymentMethodData,
errorMessage: paymentData.errorMessage,
activePaymentMethod,
setActivePaymentMethod,
onPaymentProcessing,
customerPaymentMethods,
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
paymentMethods: paymentData.paymentMethods,
expressPaymentMethods: paymentData.expressPaymentMethods,
paymentMethodsInitialized,
expressPaymentMethodsInitialized,
setExpressPaymentError,
Allow shopper to save Stripe payment method in user account for subsequent purchases (https://github.com/woocommerce/woocommerce-blocks/pull/2453) * always default "save my card for next time" checkbox to unchecked: This is based on the previous checkout behaviour. I.e. the shopper has to actively opt-in to save their card. * Implement "save payment method for next purchase" in checkout: - send "save card" option using existing post key - wc-stripe-new-payment-method - comment out inappropriate use of "save" when using a saved card (tbc) * don't hard code the payment gateway name in 'save payment method' key * refactor "save payment info" checkbox so payment methods can opt-in: - Add options.allowSavePaymentToken to payment method registration / config. - Opt-in in Stripe CC, it allows saved cards. - Remove render of "save my card" checkbox from Stripe CC UI component. - Render "save my card" checkbox automatically in payment method tab (based on allowSavePaymentToken option). + todo/follow up comments * rejig "save my payment method" behaviour so it's generic: - Any payment method that supports "save" can opt-in: - options.allowSavePaymentToken = true/false - handle `wc-XXX-new-payment-method` key server side to persist - Add support in payment context/state reducer for storing checkbox state, expose value and action via context - Convert state flag to appropriate API key/value in payment processor - Remove previous stripe-specific implementation + bonus add comment to payment context about preserving state in PRISTINE action * rename payment method "allow save" option, more consistent with UI * remove last vestiges of gateway-specific "save card" impl: - No need to pass CheckboxControl to payment methods; checkbox is now handled automatically by checkout. - Remove shouldSavePayment prop passing through various layers of stripe payment processing code. (Now handled in context/processor.) * change new option property name and shape. Also adds validation. * update type-defs * use more reliable `activePaymentMethod` for saved payment method Co-authored-by: Darren Ethier <darren@roughsmootheng.in>
2020-05-12 15:12:28 +00:00
shouldSavePayment: paymentData.shouldSavePaymentMethod,
setShouldSavePayment,
};
return (
Refactor logic for handling active payment method with express payment methods via checkout (https://github.com/woocommerce/woocommerce-blocks/pull/2170) * remove logic server side for getting payment method from paymentdata * ensure stripe accounts for payment request type payment methods * make sure legacy payment method handling always runs last * add processedPaymentMethodId to payment method data context state * switch checkout processor to use new processedPaymentMethod id for submission * implement returning paymentMethodId from payment-request-express * include paymentMethodId in stripe cc success return value * include paymentMethodId in cheque success return value * add active payment method setting and handling via checkout express payment methods still need to implement: - onClick when their button is clicked - onClose when the express payment interface is closed (cancelled etc). * don’t expose setActivePaymentMethod on the payment method interface * remove/fix artifacts from earlier iterations of the pull * rename `id` property to `name` property for payment method registration * Revert "include paymentMethodId in cheque success return value" This reverts commit fe4ee8aced6d67bbd9033263ce61844349d18250. * Revert "include paymentMethodId in stripe cc success return value" This reverts commit 359a1f0089866110ec204182f8ffa14ab099c425. * Revert "implement returning paymentMethodId from payment-request-express" This reverts commit 117c68980b0876dee0acc78cec7754ccfe2a9bb1. * Revert "switch checkout processor to use new processedPaymentMethod id for submission" This reverts commit c38a05b63626dfc1336c7bb0e86417b798a803d6. * Revert "add processedPaymentMethodId to payment method data context state" This reverts commit 3d7923e7297f3c76efde536d26eaf68464ba9583. * improve isSuccess response check and variable name * implement paymentMethodId config option * doh php ain’t javascript * add missing dependency from rebase
2020-04-09 15:22:34 +00:00
<PaymentMethodDataContext.Provider value={ paymentContextData }>
{ children }
</PaymentMethodDataContext.Provider>
);
};