woocommerce/plugins/woocommerce-blocks/assets/js/payment-method-extensions/payment-methods/stripe/credit-card/index.js

65 lines
1.6 KiB
JavaScript
Raw Normal View History

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
/**
* External dependencies
*/
import { __ } from '@wordpress/i18n';
import { useEffect, useState } from '@wordpress/element';
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
/**
* Internal dependencies
*/
import { getStripeServerData, loadStripe } from '../stripe-utils';
import { StripeCreditCard, getStripeCreditCardIcons } from './payment-method';
import { PAYMENT_METHOD_NAME } from './constants';
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
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 stripePromise = loadStripe();
const StripeComponent = ( props ) => {
const [ errorMessage, setErrorMessage ] = useState( '' );
useEffect( () => {
Promise.resolve( stripePromise ).then( ( { error } ) => {
if ( error ) {
setErrorMessage( error.message );
}
} );
}, [ setErrorMessage ] );
useEffect( () => {
if ( errorMessage ) {
throw new Error( errorMessage );
}
}, [ errorMessage ] );
return <StripeCreditCard stripe={ stripePromise } { ...props } />;
};
const StripeLabel = ( props ) => {
const { PaymentMethodLabel } = props.components;
const labelText = getStripeServerData().title
? getStripeServerData().title
: __( 'Credit / Debit Card', 'woo-gutenberg-products-block' );
return <PaymentMethodLabel text={ labelText } />;
};
const cardIcons = getStripeCreditCardIcons();
const stripeCcPaymentMethod = {
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
name: PAYMENT_METHOD_NAME,
label: <StripeLabel />,
content: <StripeComponent />,
edit: <StripeComponent />,
icons: cardIcons,
canMakePayment: () => stripePromise,
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
ariaLabel: __(
'Stripe Credit Card payment method',
'woo-gutenberg-products-block'
),
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
supports: {
Change payment processing for subscriptions (https://github.com/woocommerce/woocommerce-blocks/pull/3686) * Remove savePaymentInfo check when displaying payment methods This is because the savePaymentInfo is derived from whether the save payment method checkbox shows. This check doesn't make sense to do because it's not a good indicator of whether the payment method is enabled. Subscriptions for example hides the checkbox because it is implied that the method will be saved. We should instead rely on the server-side to only send permitted saved payment methods. * Add safely_get_request_payment_method This will allow us to try to get the payment method if it was passed in the request, but will default to an empty string if not. This is different to get_request_payment_method because it doesn't throw any errors. We need it to be different because get_request_payment_method is used when the order definitely needs payment (so a normal checkout scenario, vs. a £0 subscription checkout) * Add action to update order meta when checking out This is needed because some extensions rely on this action to add their information to the metadata of order items. * Remove safely_get_request_payment_method This is no longer needed. * Remove @since from experimental hook * Add PHPDoc for new update_order_meta hook * Document use of experimental hook * Reinstate the check for allowing saved cards * Add method to Stripe integration to determine if saved_cards is enabled * Add new field to get_payment_method_data This adds displaySavePaymentMethodCheckbox which will be used to determine if the checkbox to save payment methods should display. * Add displaySavePaymentMethodCheckbox option to client This will determine whether the "Save payment information" checkbox will be displayed. * Add requiresSaving option to Stripe payment method data This is informed by the saved_cards option and the result of the wc_stripe_display_save_payment_method_checkbox filter. * Rename displaySavePaymentMethodCheckbox to requiresSaving & fix logic * Revert negation on display_save_payment method_checkbox filter & rename We are going to rename the properties we use to determine whether saved cards are shown, or whether the save payment method checkbox is shown, so that their names are more descriptive of what they are for. * Rename allowSavedCards and requiresSaving in Stripe integration * Rename savePaymentInfo&requiresSaving to showSavedCards & showSaveOption This is so we can hide the checkbox independently of hiding the saved payment methods. * Show deprecated message if payment methods use savePaymentInfo This is because we are leaving it in to enable backward compatibility but payment methods registering using this should be informed of the change in case it gets removed. * Update Stripe typedefs and keys of supports object * Show customer payment methods if showSavedCards is true on the method * Make PaymentMethodTab accept showSaveOption prop This will allow us to show the save checkbox only if the payment method says it should be shown. * Update tests to use new keys in supports when reg'ing payment methods * Add optional chaining when validating payment method config This makes the code a little tidier :) * Update assets/js/blocks-registry/payment-methods/payment-method-config.js Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com> * Add more information to deprecated call in payment method config * Fix lint error * Fix prop types for PaymentMethodTab * Add information about supports on payment methods to docs Co-authored-by: Seghir Nadir <nadir.seghir@gmail.com>
2021-01-24 13:59:13 +00:00
showSavedCards: getStripeServerData().showSavedCards,
showSaveOption: getStripeServerData().showSaveOption,
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
},
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
};
export default stripeCcPaymentMethod;