#benkass

1 messages · Page 1 of 1 (latest)

desert flameBOT
austere stump
#

Hello

tribal mortar
#

hi hi

austere stump
#

Hmmm can you elaborate on where the failure is occurring exactly?

tribal mortar
#

heh... I want to save you the pain of reading through a novel. We (me with several of your colleagues) have been working on this for days. Yesterday they finally understood that there's something missing with stripe react native to accomplish a flow they suggested themselves.

#

To explain it simply...

austere stump
#

Is this in the deferred intent flow?

tribal mortar
#
  • We have a marketplace.
  • We want to allow people to purchase from merchants (connected standard accounts) directly after we take our cut (split payment if you will)
  • To be able to present a payment sheet to the customers with an amount displayed, Rubeus suggested firing initPaymentSheet with intentConfiguration that has the amount and a confirmHandler
  • Then within confirmHandler, we fire a server call to clone the PM generated by initPaymentSheet on the connected account, create a PI, and confirm it.

This will effectively have the connected account charge the client

The problem is that the clientSecret of this PI will mismatch with the PM generated by initPaymentSheet so the intentCreationCallback will return an error instead of success

#

so far do you follow?

austere stump
#

Yep okay

tribal mortar
#

So to avoid creating a custom UI, we needed to cheat confirmHandler and have it resolve, or if something fails on the server while creating the cloned PM and PI, return an eror

#

Now. I suggested sending an exising clientSecret from a past succeeded payment to confirmHandler. Sneaky, but it worked

#

it then resolves

#

However, I want to make it a little cleaner. I want to create a tiny patch to the library so to force it to return a success without having to pass a clientSecret

#

Looking at the library, I see that the function that handles it is:

    @objc(intentCreationCallback:resolver:rejecter:)
    func intentCreationCallback(result: NSDictionary, resolver resolve: @escaping RCTPromiseResolveBlock,
                          rejecter reject: @escaping RCTPromiseRejectBlock) -> Void  {
        guard let paymentSheetIntentCreationCallback = self.paymentSheetIntentCreationCallback else {
            resolve(Errors.createError(ErrorType.Failed, "No intent creation callback was set"))
            return
        }
        if let clientSecret = result["clientSecret"] as? String {
            paymentSheetIntentCreationCallback(.success(clientSecret))
        } else {
            class ConfirmationError: Error, LocalizedError {
                private var errorMessage: String
                init(errorMessage: String) {
                    self.errorMessage = errorMessage
                }
                public var errorDescription: String? {
                    return errorMessage
                }
            }
            let errorParams = result["error"] as? NSDictionary
            let error = ConfirmationError.init(errorMessage: errorParams?["localizedMessage"] as? String ?? "An unknown error occurred.")
            paymentSheetIntentCreationCallback(.failure(error))
        }
    }
#

I think I need to alter this:

if let clientSecret = result["clientSecret"] as? String {
  paymentSheetIntentCreationCallback(.success(clientSecret))
}

Correct?

#

If possible, I would love to find a way to return success without altering the native code, but the js code. Meaning.... intentCreationCallback is called via initPaymentSheet... hang on, let me find it online. It will be easier

#

There you can see :

confirmHandler(
  paymentMethod,
  shouldSavePaymentMethod,
  NativeStripeSdk.intentCreationCallback
);
#

and it uses NativeStripeSdk.intentCreationCallback

#

If there's a way to send back a success wihout using the native sdk, it will be cleaner

#

Know how I can do it?

austere stump
#

I don't know how you can do that, no.

#

Our React Native Eng team watches this repo

#

And they would be the best people to either help you with a patch or really to release a patch themselves.

tribal mortar
#

ok I'll post there

#

One question, with deferred intent flow, how do I retain a fee for the platform?

#

So the customer pays $10, we want to keep $1 and send the rest to the connected account

austere stump
#

Same way you would in any flow. You charge an Application Fee

#

To clarify the above, this wouldn't be specific to the deferred intent flow

#

But yeah that's how you would do it -- you just set application_fee_amount when you create your PaymentIntent on the Connected Account

tribal mortar
#

ok cool. thanks

austere stump
#

Sure