OWA-85: New payment flow #593
Conversation
…o IDM-161/IAM-Middleware
…ott-web-app into IDM-169/stripe-products
…ott-web-app into IDM-169/stripe-products
…ott-web-app into IDM-169/stripe-products
…ott-web-app into IDM-169/stripe-products
…ott-web-app into IDM-169/stripe-products
…t-web-app into PS-290-new-payment-flow
* fix: choose-plan-form redirects to /subscription and preselected offer bug fixed * fix: add 0 as port for access bridge tests * chore: revert port for tests --------- Co-authored-by: “Kire <[email protected]>
…o PS-290-new-payment-flow
packages/ui-react/src/containers/StartWatchingButton/StartWatchingButton.tsx
Outdated
Show resolved
Hide resolved
…startwatchingbutton
|
@kiremitrov123 @mirovladimitrovski thanks for your work on this feature! I'm currently reviewing and testing and I noticed that the JWP integration without access bridge doesn't work anymore. Is this expected or should it still be possible to use InPlayer (JWP) directly? If not, it means that we can't upgrade when this is merged for existing customers + InPlayer.
|
@ChristiaanScheermeijer correct, we are eliminating the old flow for JW. It will be only possible with using the Access Bridge. |
There was a problem hiding this comment.
I would make it colorless and use the Icon + CSS#fill property for colouring instead.
Should we use material-ui icons? Now we have two icons that don't match the icon set anymore 😅
There was a problem hiding this comment.
Good suggestion, but I wouldn't delay merging this PR any further and would suggest leaving this for later.
There was a problem hiding this comment.
Also, which icon set are you referring to? These are icons I got from our design team specifically to use in the new modals introduced here, and material-ui is not in place as a dependency.
| import AccountService from './integrations/AccountService'; | ||
|
|
||
| @injectable() | ||
| export default class PaymentService { |
There was a problem hiding this comment.
Should this be renamed 🤔? This is actually the AccessBridgeService integration and not a payment service. It might be confusing with the CheckoutService.
There was a problem hiding this comment.
The Access related methods are in the AccessService, these are the payment related definitions that will be the one source of truth hopefully :D. It is confirmed with @dbudzins for the naming.
packages/ui-react/src/components/PaymentSuccessful/PaymentSuccessful.test.tsx
Outdated
Show resolved
Hide resolved
| @@ -31,7 +31,7 @@ const cleengProps: ProviderProps = { | |||
| cardInfo: Array.of(['Card number', '•••• •••• •••• 1115'], ['Expiry date', '03/2030'], ['Security code', '******']), | |||
| }; | |||
|
|
|||
| runTestSuite(jwProps, 'JW Player'); | |||
| // runTestSuite(jwProps, 'JW Player'); | |||
There was a problem hiding this comment.
This is not finished yet? Will it be possible to do e2e testing with the access bridge? 🤔
There was a problem hiding this comment.
Actually we don't want to have exposed a deployed version.. We will need to come up with some mocks probably.
…essful.test.tsx Co-authored-by: Anton Lantukh <[email protected]>
If I'm correct about what you're referring to, I've already addressed them. |
| const useBillingPortalURL = () => { | ||
| const checkoutController = getModule(CheckoutController); | ||
|
|
||
| return useMutation({ | ||
| mutationKey: 'billing-portal', | ||
| mutationFn: () => checkoutController.generateBillingPortalUrl(window.location.href), | ||
| }); | ||
| }; |
There was a problem hiding this comment.
The current URL should be forwarded (now it is still using window.location):
const useBillingPortalURL = (returnUrl: string) => {
// ...
mutationFn: () => checkoutController.generateBillingPortalUrl(returnUrl),There was a problem hiding this comment.
Done. I did it a little bit differently, but I think you'll approve of it.
| @@ -61,7 +75,7 @@ const Subscription: React.FC<Props> = ({ subscription }) => { | |||
| ) : ( | |||
| <> | |||
| <p>{t('user:payment.no_subscription_new_payment')}</p> | |||
| <Button toModal="choose-offer" label={t('user:payment.view_plans')} /> | |||
| <Button onClick={onClick} label={t('user:payment.view_plans')} /> | |||
There was a problem hiding this comment.
onClick shouldn't be needed, but it's fine for now:
<Button to={modalURLFromLocation(location, 'choose-offer')} label={t('user:payment.view_plans')} />There was a problem hiding this comment.
The onClick handler is there for the isLoading state, because we don't redirect right away, but only after we get a redirection URL from an API request.
There was a problem hiding this comment.
Sorry, my previous answer to this is incorrect for this use case, I actually had a different instance of using Button in mind. You're actually right.
Done.
Description
This PR solves #OWA-85.
Steps completed:
According to our definition of done, I have completed the following steps: