#supercodepoet-payment-request

1 messages ยท Page 1 of 1 (latest)

keen drift
small phoenix
#

Just to clarify, you're referring to the stripe.paymentRequest method in our JS library?

tropic pond
#

yes, from the very beginning we have used Stripe.js and Stripe Elements to gather credit card information from the user and receive a payment token from Stripe

#

we then pass that payment token to our backend and use the Stripe API to create a customer with that payment token as the source

#

and then create a subscription with that customer that then charges with card and activates the subscription

#

we do not support async subscription creation at this time some fail subscriptions with incomplete status

#

this has worked for years and even up to three days ago

#

when we started seeing errors in our testing with the 4242 4242 4242 4242 test number and the 'tok_visa' test token

#

and it has now fully migrated to production where it is failing all new charges with payment intent issues

small phoenix
#

Thanks for that info! No, the paymentRequest function hasn't been deprecated. Do you have any IDs associated with the testing you did that we can take a closer look at? Such as the subscription ID or payment intent ID?

tropic pond
#

here is a testing payment ID: pi_3JcdnTG6SOg4bQjg1rrr0ouD

small phoenix
#

Thank you for that!

subtle peak
#

(I work with supercodepoet. We haven't been able to receive any Stripe payments since at least yesterday.)

#

(And our volume is about 1/5 to 1/10 on Stripe what it usually is.)

tropic pond
#

renewals are going through but new sign-ups are not

small phoenix
#

Gotcha, I am seeing a lot of calls to our tokens endpoint that are failing. Please bear with me while I dig into those a bit deeper.

#

Based on what I'm seeing, we're returning the following error for those calls:
{ error: { code: "invalid_number", doc_url: "https://stripe.com/docs/error-codes/invalid-number", message: "The 'exp_month' parameter should be an integer (instead, is <mes>).", param: "exp_month", type: "card_error" } }

#

It looks like we're being sent odd values for number, exp_month, and exp_year parameters within the card object.

    exp_month: "<mes>",
    exp_year: "<ano>"```
tropic pond
#

where are you seeing those errors?

#

we use Stripe Elements to collect the card information

keen drift
#

Can you share your elements snippet?

#

And can we access this on your page?

tropic pond
#

@keen drift message you the URL to look at

keen drift
#

When I try to subscribe with the 4242 card I hit this:

errors: [{,โ€ฆ}]
0: {,โ€ฆ}
detail: "Payment for this subscription requires additional user action before it can be completed successfully. Payment can be completed using the PaymentIntent associated with subscription.latest_invoice. Additional information is available here: https://stripe.com/docs/billing/subscriptions/overview#requires-action"
jsonapi: {version: "1.0"}

Learn how subscriptions work within Stripe.

#

YOu're seemingly passing through an error about 3ds authentication

tropic pond
#

that is what we thought as well

#

but this is happening on ALL cards

#

even non-3DS cards

#

and according to Stripe documentation 4242 4242 4242 4242 should not fire 3DS errors

#

@keen drift messaged you a production payment ID is that as same error for a non-3DS card

keen drift
#

Is that coming from you?

tropic pond
#

we just call createToken() with the card element created by Stripe Elements

#

we were having issues with some card testing hacking over the last couple days that we refined our API to shutdown

#

I wonder if that is from the card testing stuff

keen drift
#

yea that could be the case

tropic pond
#

could card testing put us in some kind of limbo or lock on our account

keen drift
#

Not without us telling you, i wouldnt expect

tropic pond
#

I can try an place another order with a non-3DS card on production and give you the payment ID afterward if that will help. I should fail with the same payment intent errors

#

let me know if you would like me to try

keen drift
#

We're looking at it

#

Trying to dig into why that example payment for a new sub failed, thanks for sending that

tropic pond
#

PMed you an actual production payment ID that failed as well

keen drift
#

yea already had that thanks

keen drift
#

hey i was just able to succeed the signup on your test page

#

can you confirm that yourself too?

#

Does the timing of this align with the changes you made related to card testing?

#

Ok i'm still getting the error when trying again, so must have been an intermittent success

tropic pond
#

ahhh, ok

#

this one went through pi_3JctorG6SOg4bQjg12M670eH

keen drift
#

yea that one

#

we're still digging

tropic pond
#

ok

#

our automated tests fail in our backend using 'tok_visa" or 'tok_amex_threeDSecureNotSupported' as well

keen drift
#

Alright so after working through this it's seemingly related to the card testing mitigations and your use of error_if_incomplete -- this is getting in the way of some client side actions.

I'd encourage you to continue working with support regarding the card testing, but you do have some options to unblock yourself.

First, you should make sure your customer create endpoint is captcha-protected so that the card testers can't hit that with the tokens

#

Second, you're going to want to handle those incomplete subscriptions, and the easiest way to do this which should also help with the card testing is to use default_incomplete and perform the confirmation client-side afterwards. It's flipping your integration around.

#

Right now you do:
1/ create a token
2/ create a customer with that token
3/ create a sub for that customer

Instead, you'd do:
1/ Create the customer
2/ Create the sub with default_incomplete,
3/ Return the payment intent client secret to the client
4/ Confirm that payment intent client-side with elements

tropic pond
keen drift
tropic pond
#

it seems like the default path for integration with Elements changed at some point cause the first path is the what we did following the integration with Elements originally

#

so is the path we are using just broken somehow or deprecated?

keen drift
#

it is deprecated, yes, and what you see now is what we added to reduce the number of logic branches to handle (eg, always confirm client side, don't need to check for actions required)

subtle peak
#

Do did you all deprecate what we were using on Monday? Is that why this is failing now?

keen drift
#

No its still a valid integration, as i said these errors are related to the card testing mitigations you're working with support on

#

So given that, my suggestion is to consider moving to the newer pattern which will help

subtle peak
#

Understood.

#

What I'm trying to understand now is why things broke.

#

If it was on our end, that's obviously on us. If it was on your end, that's something else to understand.

tropic pond
#

ok, so we prototyped the new way and figured out where this is breaking on our account

#

basically the payemtn intent requires_action

#

because elements wants to fire a captcha

#

and we don;t handle that

#

we jsut listen for the token to be generated

#

so the Stripe.js was changed or our accoutn was changed to require catpcha (I'm am a human) model to fire on all card submittions

keen drift
#

That's roughly correct - those captchas are the actions you need to handle

#

which isn't going to work with your error_if_incomplete approach

tropic pond
#

but doesn't that then break the official path we are using

#

@elder sage is going to create a video of this prototype

#

is there no way not to fire the captcha? we have our own Google Captcha firing before creation of subscription

keen drift
#

if you're doing mitigation separately, then you'll need to work with support to adjust the settings on your account

#

You can handle it, yes, but you'll need to not use error on incomplete to accomplish that

subtle peak
#

What's the reason these settings were applied to our account without us being alerted?

keen drift
#

I can't speak to that here -- you'll need to work with support, continuing the discussion about card testing

subtle peak
#

Okay, well let's be clear what happened when our account was changed and we were not alerted: we can no longer receive payments.

#

This is a serious risk to our business that you all can behave this way.

elder sage
#

ok, I was in the middle of recording a demonstration of that CAPTCHA popping up

#

and it no longer is doing it ๐Ÿ˜•

keen drift
#

I understand -- and we're still investigating whether something went wrong here

#

As I said I would encourage you to work with the person who was helping you with card testing

#

and here, now, i can help you with alternatives to unblock yourself

elder sage
#

thank you @keen drift

subtle peak
#

Yes, much appreciated @keen drift.

keen drift
#

Which version are you prototyping?

#

allow incomplete or default incomplete?

elder sage
#

we did "default_incomplete"

#

and we just got word back that someone opted our account into the CAPTCHA requirement

#

that it was a mistake on Stripe's side

#

that bit has been toggled off and it appears that we are operational again

keen drift
#

Awesome - ok that's great news

subtle peak
#

Thanks for the help @keen drift! (Also, seriously nice color scheme on your profile image.)

keen drift
#

๐Ÿ˜„

#

Quite welcome - I'm glad to hear we were able to get you unblocked, apologies for being coy about it here.

#

We'll be in touch about this with more detail later, so watch for emails from us.