tipsi-stripe

tipsi-stripe copied to clipboard

Are you going to insert support for new Stripe PaymentIntents API?

I've already +1 one this, and if you plan on supporting this, I'm curious about the timeline as the September 2019 deadline is fast approaching.

Any update on this?

@enda-phorest integration doesn't look very hard. But probably tipsi team will implement it only if there are no other options. Probably someone will need it before that and send a PR

Any update ?

Also wondering if there is any update?

Hi everyone,

Two days ago, I have sent a message to Stripe to get some update about SCA compliance and integration with or without third-party.

To resume, the answer is pretty clear: check with Tipsi OR do your own integration.

@TipsiTeam: Do you plan tu support this feature before September?

« Hello,

This is Mitch with Stripes SCA team stepping in here, I hope this email finds you well.

Reading through your chat here I see you are using React Native and want to know how to get your integration set up to be SCA compliant. One thing to mention is that most of our third party integration have not completed their SCA updates yet. Partially because not everything is fully moved over yet on our end either. Most are waiting until all of the products and features are done being updated before they change their set up. This puts a lot of companies like you in a bind because you rely on these third parties but they are not ready yet.

So first and foremost I would reach out to Tipsi about this and find out what their plans are. Then I would using that information plan on what you are going to do to be ready when September rolls around.

Stripe offers a few easy integration options such as Checkout which now uses payment intents to allow for 3DS and SCA compliance:

https://stripe.com/docs/payments/checkout

But instead of redoing your whole integration first as I said reach out to Tipsi and see what they plan to do and then go from there. If you have further questions I'm always happy to help.

Best wishes, »

@dziter our answer remains unchanged: we will do integration if we don't get any PR from the community.

Because our major market is the US we don't have tight deadlines for it as other companies who are working in the EU. So there is no ETA from our team, we will do it when we have time for it.

Thanks for the update @dziter and @cybergrind. For more EU focused companies, a PR from the community seems more realistic if you have no ETA at Tipsi.

First of all a huge thanks @cybergrind and the tipsi team for your hard work on this project.

As a UK based product that relies on Stripe we're being forced to move from using the Charge API to the Payment Intents API due to strong customer authentication.

Having read the comments above I totally understand that adding support for Payment Intents isn't a priority for tipsi. However, given the popularity of this library (7,108 weekly downloads at time of writing this) having no clear roadmap for this is quite concerning since literally, our whole business won't be able to operate from September 14th without this migration.

Personally, I'd love to be in a position to contribute a PR but as a super small team of two with no Objective-C or Java experience, this wouldn't really be practical.

Again, to reiterate I get that this isn't at all a tipsi's problem. The library is clearly used by so many companies and products that will be affected. I think we collectively need to devise a clear roadmap and solution to this problem to ensure that all these businesses aren't affected.

Given the breadth of people dependent and that it is currently the only react native library for Stripe I'd be inclined to ask Stripe directly if they are able to contribute. Alternatively, has anyone else got experience in crowdfunding the work needed to add support to this open source project?

I hope you don't mind but I'm copying in some of the top two recent contributors from each of stripe-node, stripe-android and stripe-ios to see if they are able to support (@ob-stripe @remi-stripe @mshafrir-stripe @ksun2-stripe @yuki-stripe @csabol-stripe).

@adambutler thanks for raising this, all valid and time-sensitive points. +1 to thanking @cybergrind and team for maintaining tipsi for the react native community + Stripe customers. We know this project is a lot to maintain and open source contributions are why react native developers are able to quickly implement payments.

We're talking internally today on setting a plan and will get back to this thread in short order.

@trag-stripe API changes itself isn't that hard. E2E tests are the issue:

• #470 blocked by fixing tests and it is blocking all new PRs
• #448 will require new tests.

So implementing new APIs is 15% of the time, fixing and writing tests - 85%. So it probably will consume at least full week of the one developer and we cannot make this commitment right now.

Ok, thanks for the context - makes sense that payment methods, intents, and the required tests need to been seen as all part of the overall work that's required. We had a kick off this morning and are planning to submit relevant PRs to contribute to tipsi-stripe. (Work & progress will be over the next few weeks)

👏 Amazing response from both the tipsi and Stripe teams. Thank you.

I have implemented payments intents based off Tipsi for our app. Happy to review PRs when added properly.

@tomrevansecho do you have a fork for what you did please ?

Unfortunately no due as I wasn't sure about the level of PCI compliance and have used native components from Stripe SDK for both iOS and Android. I wrote the bridge for both iOS and Android and this project was a huge help, is some tidy up still to do.

I would love to contribute back, its finding the time is the hard part. The Stripe docs were not the easiest to follow but I was lucky I had already done the web implementation, so I didn't require any further backend changes for this.

The biggest thing to implement is the action for further verification, this was the Android implementation roughly.

` @ReactMethod public void handleCardAction(ReadableMap params, Promise promise) {

    String paymentIntentClientSecret = params.getString(FIELD_PAYMENT_INTENT_CLIENT_SECRET);

    if (paymentIntentClientSecret != null) {

        try {
            final PaymentIntentParams retrievePaymentIntentParams =
                    PaymentIntentParams.createRetrievePaymentIntentParams(
                            paymentIntentClientSecret);

            AsyncTask.execute(() -> {
                try {
                    // retrieve the PaymentIntent on a background thread
                    final PaymentIntent paymentIntent =
                            mStripe.retrievePaymentIntentSynchronous(
                                    retrievePaymentIntentParams,
                                    BuildConfig.StripeKey);

                    if (paymentIntent != null && paymentIntent.requiresAction()) {

                        Uri redirectUrl = paymentIntent.getRedirectUrl();
                        if (redirectUrl != null) {
                            if (getCurrentActivity() == null) {
                                promise.reject(
                                        getErrorCode(mErrorCodes, "paymentIntentRetrieveFailed"),
                                        getDescription(mErrorCodes, "paymentIntentRetrieveFailed")
                                );
                            } else {
                                mPromise = promise;
                            }

                            getCurrentActivity().startActivity(
                                    new Intent(Intent.ACTION_VIEW, redirectUrl));
                        }
                    } else {
                        promise.resolve(paymentIntent.getId());
                    }
                } catch (Exception ex) {
                    promise.reject(toErrorCode(ex), ex.getMessage());
                }
            });
        } catch (Exception ex) {
            promise.reject(toErrorCode(ex), ex.getMessage());
        }
    } else {
        promise.reject(
                getErrorCode(mErrorCodes, "paymentIntentParameterMissing"),
                getDescription(mErrorCodes, "paymentIntentParameterMissing")
        );
    }
}`

and for iOS:

` @objc func handleCardAction(_ params: Dictionary<String, String>, resolver: @escaping RCTPromiseResolveBlock, rejecter: @escaping RCTPromiseRejectBlock) {

if let paymentIntentClientSecret = params[RNStripeManager.field_payment_intent_client_secret] {
  
  STPAPIClient.shared().retrievePaymentIntent(withClientSecret: paymentIntentClientSecret) { [weak self] (paymentIntent, error) in
    if let paymentIntent = paymentIntent, paymentIntent.status == STPPaymentIntentStatus.requiresAction {
      
      guard let redirectContext = STPRedirectContext(paymentIntent: paymentIntent, completion: { clientSecret, redirectError in
        
        guard redirectError == nil else {
          rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
          return
        }
        
        // Completion block when any redirect flow is done
        STPAPIClient.shared().retrievePaymentIntent(withClientSecret: paymentIntentClientSecret) { confirmPaymentIntent, error in
          if let confirmPaymentIntent = confirmPaymentIntent, confirmPaymentIntent.status == STPPaymentIntentStatus.requiresConfirmation {
            
            resolver(confirmPaymentIntent.stripeId)
            
          } else {
            rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
          }
        }
      }) else {
        
        // Unsupported by Stripe
        rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
        return
      }
      
      if let strongSelf = self {
        strongSelf.redirectContext = redirectContext
        
        // TODO - ... bad practice
        let appDelegate = UIApplication.shared.delegate as! AppDelegate
        redirectContext.startRedirectFlow(from: appDelegate.window.rootViewController!)
      } else {
        rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
      }
    } else {
      rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
    }
  }
} else {
  rejecter(RNStripeManager.error_code, RNStripeManager.error_stripe_unknown, nil);
}

}`

I will try and can get some time but I can't promise anything - happy to review any PRs if anyone makes an earlier start.

is anyone still working on PaymentIntent for tipsi-stripe?

Comment from trag-stripe above indicates that Stripe will kindly do a PR for this issue quite soon.

@trag-stripe can you provide any updates on this?

Hi @enda-phorest / @bamdadd / @matthiasleitner - mini update here:

PaymentIntent / SCA support has been in active developement for the last two weeks - point developer on our team is @mindlapse. Context: Beyond PaymentIntents, there were a few pre-existing issues we agreed to resolve around CI Builds and migrating to the latest versions of our Mobile SDKs.

You can track the key PRs here as they land: https://github.com/tipsi/tipsi-stripe/pulls/mindlapse

@trag-stripe thank you very much for the mini update. We can't wait for this piece of work and excited that Stripe is getting involved directly !

@mindlapse do you think you can point us to a particular PR for supports on PaymentIntents ?

@trag-stripe thanks for the update! @mindlapse As the deadline for SCA is approaching would be glad if you could share some details about your internal timeline.

Happy to support on certain PRs if possible.

I'm thrilled to hear that you're working on this @trag-stripe / @mindlapse! Do you recommend using a particular branch? or are they merging right into Tipsi-Master? We're kicking off our backend work, and we want to start adopting tipsi-stripe (we don't currently have stripe in our RN app). So I would love to use the right codebase!

Please give us an update

Ideally we'll be bringing the payment intent changes into master. At the moment we're working through quite a few Travis pipeline/Android emulator/Appium issues to unblock the PRs, and the biggest priority once those are resolved is to bring in the PaymentIntent changes.

@fbartho I know you're interested in a preview build so I'll look to get one set up soon!

I'm excited to hear that development on support for the Payment Intents API is in progress. Thanks to all those working on it, particulary @mindlapse for taking point.

The Tipsi libary is a key part of our mobile products, and so as you can imagine i've ben keenly tracking this Issue for a resolution.

Could you please share an upate with where you are, and if possible share the outstanding PR's? I am happy to contribute where possible to getting this over the line given it's importance to us (and many others I'm sure), so let us know if there is anything the community can do to help.

Hi all, Really glad to see the interest, there are a couple of gaps where we could use some help.

• [ ] (in progress by @mindlapse) Stabilizing the android CI pipeline
• [ ] (in progress by @mindlapse) Adding 'AppInfo' changes for Android that identify tipsi-stripe as the client for transactions made through it
• [ ] Adding the same 'AppInfo' changes as above, except for iOS
• [ ] Stabilizing the iOS build pipeline (i.e. so that it doesn't time out from inactivity)
• [ ] Integrating the above into a branch that contains changes for Payment Intents
• [ ] Updating the example app with demo pages using test cards that demonstrate supported payment intent use cases
• [ ] Enhancing the CI pipeline test suite to validate that the test pages operate as expected (and that the existing test suite continues to pass)

Our biggest gap at the moment is with the iOS pipeline - we're seeing timeouts on Travis. We need someone to look at the iOS pipeline, and to determine if the timeout can be solved on Travis open source build machines, or if we need to move to something like real device testing or a provider that specializes in mobile app testing like SauceLabs. The GitHub Sponsors program may be a good option to help cover the subscription costs if we go that route.

In terms of PRs, there is #470 which contains changes related to payment intents, these changes will need to go through a review and will need a test suite created and the example app updated. The changes are really appreciated - I'm looking forward to helping review them.

My focus today is on finishing up the stabilization of the android pipeline, which is nearly ready (i.e. with emulation that doesn't timeout) and I expect to have a PR for those changes soon.

So that's the update! Thank you for checking in - if you know someone who can volunteer with the iOS pipeline and iOS AppInfo changes, that would be really helpful with moving this forward.

Thanks for the updates, I'm also following this repository. Depending on the timeline I was considering using a web view inside my RN app in the meantime. Do you guys see any major downside to this approach?

Hi @hugoh59 am also doing the same, and manually handling redirection using the next_actions object and as far as i know, It is only method to go with tipsi stripe and performing 3d secure using paymentIntent for now. However I am stuck on creating paymentMethod using tipsi-stripe (since we are not a PCI compliant firm, paymentMethod has to be created in client side). Can anybody help me with that?

@shubhamkes we are creating paymentMethod on the client side and doing the paymentIntent work on the server side. Here is our fork: https://github.com/b-social/tipsi-stripe We are still working on it and its not in production yet. But we did some dev testing and it seems to be working on both android and ios