#jeremyflores-connect-issues

1 messages ยท Page 1 of 1 (latest)

worn herald
#

๐Ÿ‘‹ What's your issue?

indigo kestrel
#

we have a tester that's creating a Stripe Connect account, and we are seeing an issue with the verification process

#

basically, the SSN is being rejected, but we don't know why

#

the tester has entered the full "gov id number" through our systems, and we have confirmed that it's being submitted successfully to your api

#

and, we have also entered it manually using Stripe Dashboard

#

in both cases, we keep seeing id_number in the "requirements" section of that stripe connect record

worn herald
#

Hmmm this seems to not be code related or anything and just that our systems think the SSN is invalid right?

indigo kestrel
#

exactly

#

we've been in touch with the CSRs, and have received a couple of conflicting answers

#

one person suggested that there's an internal system error on stripe's side, someone else said that we need to submit the physical documents

worn herald
#

Unfortunately this is really about someone's real identity about one account. It's not something I can really debug here. But I can tell you it's not a coding/integration issue and if we ask for the SSN again it's because we think it's invalid or doesn't match their official details (name and DoB) since we talk to a partner to verify that information

indigo kestrel
#

ok, in that case, it would be helpful to understand the workflow here...

#

so, someone had mentioned that we need to submit physical documents

#

it would be great to understand a couple things around this...

worn herald
#

physical documents is an alternative when the rest can't be verified yes

indigo kestrel
#
  1. right now, we are seeing government id_number as a requirement--is there a particular representation in stripe for the case where the physical documents need to be submitted in the stripe connect record?
#

i.e. is there a way for us to know when the physical documents need to be submitted programmatically (vs just submitting the full SSN/id number)

worn herald
#

we always require SSN and document is an alternative

indigo kestrel
#
  1. ok, so the user can submit one or the other, but it's never expected that they submit both together?
#
  1. and, as a result: when we see id_number in the requirements section, that is meant to represent that the user must submit either the full gov id/ssn, or they can instead submit the physical docs to satisfy the requirement?
#

3a) is there a rationale for why a user would use one instead of the other? is it purely for cases where a user may have some kind of physical doc but not a gov id number, or are there other considerations in mind? this would be helpful to understand as we consider any ramifications on our productization

#

3b) or is it that, should the id number verification fail, the physical document is seen as a backup verification process? i.e. it is not that the user, at the beginning of the workflow, is expected to freely select either inputting the id number or the physical docs, but rather there is an implicit ordering where the user should first enter the full id number, and then contingently enter the physical docs should the full id number fail to complete the verification

#

4a) related to our productization, it would be useful if we could communicate to users--including our current tester--why the verification is failing for a full gov id. is there a way to programmatically extract any kind of information from the stripe api, e.g. even just a simple error msg?

#

4b) if not, is there any documentation, or at least some list of reasons which can be shared here, that we can refer our users to (or, in the case of a list, directly embed in our workflows built atop of stripe connect, or at least ad hoc communicate to users who experience this issue)?

#
  1. in either a live or test environment, is there a way to trigger the full workflow where all cases are covered? i.e. if there are conditions wherein physical documents are required, it would be good for us to be able to reliably trigger these workflows so that we can test our systems against these states in stripe's systems
worn herald
#

Sorry I went into a meeting, catching up

indigo kestrel
#

no problem! thanks for following up

indigo kestrel
#

i need to step away for a couple mtgs but will return in a bit--thanks again for the insights you can provide on these questions!

jaunty flame
#

๐Ÿ‘‹ I'm taking over for @worn herald and am in the middle of writing some answers! They should be there by the time you're back

jaunty flame
#
  1. I believe it depends on the country/other circumstances. - typically they would submit ssn, but if additional verification was needed they would also need to provide the document.
  2. This means they must submit the id_number. They would only submit the document if the requirements section like {{PERSON_ID}}.verification.document
    3a/b) Same answer as above - it's not a "one or the other". The user needs to provide the gov ID at some point, but if we can't verify it then we ask for the document
    4a/b) I believe that's something you would find in requirements.error. Beyond the information provided there, I don't believe we provide any further details
#

I'm still looking in question 5!

#

It walks through the correct test values needed to trigger certain verification states

indigo kestrel
#

hi karbi, thanks for the answers

#

i'm reading through them now

#

ok, just so i understand a key point:

#

sometimes, it's sufficient that a user enters in the last 4 of SSN (for US users)

#

in which case, we will not see any requirements related to gov id/physical docs (we have seen this empirically)

#

in other cases, stripe will sometimes ask for the full id_number, in which case this is presented as verification.id_number in the stripe connect record in the requirements section

#

now, if the user has already provided the full id_number, and stripe still fails to verify that person's identity--only under these conditions would we see the request for a document yeah? i.e. only after the user has submitted the full id number would it be possible for us to see verification.document for that stripe connect record

jaunty flame
#

Give me one minute - I'm reading back on some internal docs and just want to make sure everything I've told you already is correct

indigo kestrel
#

cool, thank you for checking!

jaunty flame
#

Ahhh sorry archived the wrong thread

indigo kestrel
#

no problem!

jaunty flame
#

Okay, so here's my current understanding (I was a bit wrong about some earlier points):

  • You can technically provide a document in lieu of a SSN. We prefer to ask for last 4 because down the line we may need it for tax reasons (I believe this is dependent on your volume/other factors but I'm not 100% sure what those factors are).
  • One reason someone may want to provide a document instead of a SSN is that maybe they have a non-US representative (who wouldn't have an SSN)
  • Even though we accept document as a replacement, it won't be reflected in the requirements section at that time (because we prefer to get back the last 4 ssn).
  • Other verification requirements (like unverified dob and address) may also trigger the document requirement. In terms of SSN, I believe our prefrence is that we ask for last 4 -> full SSN -> and then the document, but you can provide the document at any time
indigo kestrel
#

ok, got it

#

so this leads me to a problem we are currently observing

#

with a tester on a "live" stripe mode (i.e. not test/dev)

#

namely:

#
  1. they enter their info like name, dob, address, bank info, last 4 of SSN
#
  1. their stripe connect record shows "verification.id_number" as being due
#

3a) tester goes into our system and enters full SSN/gov id number. i have manually verified in browser dev tools that this is being successfully submitted to stripe API with 200 OK response

#

3b) i have also gone into stripe dashboard and manually entered their full SSN/gov id number

#
  1. in both 3a and 3b cases, we see no state change in the stripe connect record. i.e. it continues to report verification.id_number as the only requirement
#

we built our system with this expectation in mind: I believe our prefrence is that we ask for last 4 -> full SSN -> and then the document, i.e. that was our understanding as well

#

BUT, for some reason, we are not seeing this state change when the full SSN is provided. i.e. we would expect to see one of four possible outcomes in this case:

  1. stripe rejects the input with 4xx, i.e. the SSN was badly formatted or something
  2. stripe accepts input with 200, and stripe connect record is transitioned to verified state
  3. stripe accepts input with 200, and stripe connect record is transitioned to rejected/restricted state
  4. stripe accepts input with 200, and stripe connect record is transitioned to having verification.document in the list of requirements
#

instead, we see:

  1. stripe accepts the input with 200, and stripe connect record undergoes no mutation
worn herald
#

My understanding is that we don't do option #4, we only ask for SSN and you can optionally try to submit a document instead

indigo kestrel
#

at what time does stripe ask for verification.document then?

#

when using the test system inputs, we can do 1111 for last 4 of SSN

#

which triggers verification.id_number

#

then, if we put in 111111111 for the full id_number, this will trigger verification.document

#

i'm having a hard time reconciling this test workflow with what we are currently observing in live mode

worn herald
#

I unfortunately do not know I'm sorry. I discussed it with @jaunty flame on our side and we don't know the specifics of at which point we move to asking for the document explicitly. The best option is to talk back to our support team since you have a really clear question they can look into
My advice is to treat the ask for id_number as a signal to collect the document if you already submitted the id_number and it failed

indigo kestrel
#

i understand, but the difficulties with the support team is why i transitioned the conversation to be here with stripe

#

i.e. especially since there is a discrete technical point that would be helpful in eludicating (again--i understand that this is beyond the scope of your knowledge)

worn herald
#

That's totally fair and we're always happy to help here, but this is reaching a point where we unfortunately can't. We won't get you a real time answer, it will likely take days to get to the bottom of it (hence my approach of just treating that requirement differently to start)

indigo kestrel
#

our concerns are variegated at this point from the problems we are currently facing:

  1. the live system at least appears to behave differently from the test system--in our own testing, we have been unable to trigger the verification.document state by deliberating entering erroneous SSNs, and the tester, as far as we know, has for weeks been correctly entering their personal information, yet the SSN is being rejected and we are not seeing any state changes

  2. it is unclear at what point exactly we should present the physical document submission option to the user--one would reasonably expect this to be conditional on seeing verification.document, but, again this is either not the case, or there is a failure in stripe's systems such that this state should be created but is not

  3. if we must accept the current state representation of the stripe connect record as-is, then we do not have clear ways of understanding how best to interpret the requirements section according to this id_number / verification distinction

worn herald
indigo kestrel
#

ok, i can do that--however, i have already been in email communication with stripe representatives, i.e. i've been trying to get to the bottom of this issue for weeks and have done chats with stripe CSRs, and some of those conversations have also been elevated to email level while people have done investigations. unfortunately, that has not been a fruitful endeavor

#

as i believe i had stated earlier, there have been contradictory messages received, even in the same email thread from various stripe CSR members

#

i am, unfortunately, no closer to resolving this issue

worn herald
#

what do you call a "CSRs"

#

Do you have an example account id I can look at? I can maybe find who you're talking to and see what they are saying?

indigo kestrel
#

oh, by CSR i mean the folks that i spoke with over the stripe customer service chat

#

and then that has been escalated to some email threads

#

let me look to see if i can find some ids in the email threads

#

i see this at the end of various emails: ML09WZ-PV0K

worn herald
#

I need an account id from your end instead.

indigo kestrel
#

which kind of account id? the stripe connect account id that we are seeing issues with, or my stripe acct id, or something else?

worn herald
#

the former

#

the connected account id specifically

indigo kestrel
#

acct_1JVOmdR5LxTMjM1o

#

at this time, the acct has automatically transitioned to Restricted state because the expiration date has passed

#

but, prior to that, we were not able to make any changes happen on it

worn herald
#

hum

#
  "currently_due": [
    "id_number"
  ],
  "errors": [

  ],
  "eventually_due": [
    "id_number"
  ],
  "past_due": [
    "verification.document"
  ],```
#

that account clearly says you need a document and it's past due right? But it is also asking for SSN (there are cases where we will need the SSN no matter what, usually associated with the account's processing volume for example)

#

I thought you said we were not asking for document?

indigo kestrel
#

it did not say document before

#

hang on

#

ok, you're right, it says verification.document now

#

however, i still see when i had last looked it up in the terminal

#
    "alternatives": [

    ],
    "current_deadline": 1631231541,
    "currently_due": [
      "individual.id_number"
    ],
    "disabled_reason": null,
    "errors": [

    ],
    "eventually_due": [
      "individual.id_number"
    ],
    "past_due": [

    ],
    "pending_verification": [

    ]
  },```
#

i will have to look through our webook logs for when that transition occurred, b/c that had not been the case for quite a while

#

so, one question here is: i do know that the acct recently transitioned to a restricted state--is that a criterion for triggering the verification.document state? or it's possible that, if the acct is still in a Restricted Soon state, we may see verification.document occur?

worn herald
#

I don't think so

indigo kestrel
#

secondarily, how should we interpret the case where we see both id_number AND document? the tester had already provided the full SSN, and i had also manually entered the full SSN via stripe dashboard in this case--does that mean that the full SSN provided has been rejected? or does it mean that, if the phyiscal documents are provided, this may satisfy both the id_number and document requirements?

worn herald
#

it's restricted because something is past due

#

Okay looking at the events the main one is the last account.update which is when the account became restricted and we started asking for the document
I also see your asks to our support team though there are numerous extremely complex asks and unfortunately for something this advanced it will always take some time

indigo kestrel
#

yes, i understand that it may take some time--my concern has just been making sure the general trajectory has been correctly set, especially given the complexity. i want to be mindful of everyone's time

#

one thing i can say is that this has been a consistent issue with this particular tester, i.e. we have had them go through and create multiple stripe connect accts from scratch and we have observed similar behavior across the board

#

as a next step, i'd like to ask them to try again and create a new stripe connect acct from scratch, and see if we can once more repro this issue

#

seeing the verification.document in the requirements is great news, and satisfies all our concerns--provided that we can't repro this issue again

#

however, in the event that we encounter this problem once more--it would be great if i could revisit this topic

worn herald
#

I still feel like something is wrong that we ask for document only when we disable

#

it seems off

#

unfortunately this is really way beyond the scope of what we can answer here

indigo kestrel
#

ah, i misunderstood your earlier statement!

#

you are saying that stripe's account update action to mark the record as restricted, not one of the user's account update actions, is when verification.document was set

worn herald
#

yes based on the event I saw, we seem to disable the account and at the same time say "document is past due" but we didn't ask for the document upfront

#

Unfortunately I have no idea why and this is way too specific to this situation so I won't be able to find you an answer I'm sorry

indigo kestrel
#

no problem, i feel like some definite progress has been made on this issue!

#

part of the confusion on our side is if we were misunderstanding the expected behavior on stripe's side

#

but your expectations here are in line with ours for how this stuff is supposed to behave

worn herald
#

yeah, overall I would treat the "if SSN was entered and failed, ask for the document"

indigo kestrel
#

ok great, so for next steps--i can follow up with the email thread that's been ongoing, mention that i had been conversing with you and karbi on discord, and report this finding that you have discovered

#

would that be a good way to continue things on stripe's side?

#

or do you have some other recommendation on how to escalate this?

worn herald
#

yeah that's the best way. I left a note on the ongoing "ticket" you have too with more details

indigo kestrel
#

excellent, thanks so much for the support here! like i had said--extremely helpful to get some feedback on this

worn herald
#

Of course, really sorry for the struggle. All I can do is say that this is really hard

#

this is also why we built Connect Onboarding in the first place

indigo kestrel
#

cool, i will look into that as a possible alternative. thanks again, and have a good weekend!