#stripe

If you're asking for their card info each time I would question using stripe customers in the first place

is it acceptable practice to displace a charge ID ch_* to the end user?

*display

vasp: its fine but it's not the most user friendly

yeah, thats quite true. I figured putting it somewhere in the technical details area of the invoice (just to help resolve any issues, since it serves as a reference)

I'm working with Stripe Checkout, flask, and AWS Lambda. I'm pretty confused on what is happening. When I run a test payment, Lambda throws a 401 error saying Invalid API Key provided, but Stripe's logs show 200 with the provided information. What's going on?

houston: does the stripe log only show the token request or does it show the charge request too?

mattwc: only the token request

So that would confirm that your lambda request is indeed failing

Alright, that limits my figuring out the error to the Lambda environment variables. That helps.

Hello, is stripe.js available on npm?

Also would it be possible to use stripe.js/v2 instead of v3? We have our own custom elements, and we need to validate bank account information. Which AFAIK stripe.js/v3 doesn't offer.

stripe.js/v3 feels and looks like a total pain for us. On top of that it doesn't seem to be offered on npm. The reason for that, I have no clue. But it is a huge pain for me at my company. Mainly because we lazy load all our dependencies until they are used and stripe.js script loading makes it difficult to do.

Can someone at stripe please tell me why stripe.js isn't available on npm?

On top of this why are some of the API's for validation unavailable on stripe/v3?

This makes it doubly more painful and unlikely we will upgrade, because to use the missing API's we need to load BOTH stripe versions....

ugh.

As it states here: https://stripe.com/docs/stripe-js/v2#bank-accou...

If you need to perform bank account validation, use Stripe.js v2 for both collection and validation.

but if we need to collect PII data: https://stripe.com/docs/stripe-js/v2#collecting...

It's apparently deprecated.

This is incredibly frustrating and uninuitive.

unintuitive*

We have a lot of infrastructure related to our elements that depend on the validation methods for bank/cards/etc. and it's so frustrating that these aren't available first class and instead are only available through elements. Talk about throwing away thousands and thousands of hours we've spent engineering them to our liking and usefulness with hooks for analytics and much more.

Please, provide these methods back to stripe.js and please put it on npm. It will make our application bundling and build pipeline much simpler. While preserving our infrastructure.

Experimenting with custom account for Japan

Using Kana input but it requires same thing for Kanji?

Anyone on?

when setting payout schedules, how does it work exactly with the "manual" method. Do I set the schedule once (and that will affect all payouts for all charges) OR... do I set a payout per charge and that payout schedule will only affect that respective charge?

I'm guessing the Big Wigs are sleeping by now. I know I will be in about five minutes. But the good news is I _think_ I'm ready to give this another test tomorrow morning and this time I think it should work.

nice

:)

ok heading off to dreamlandia

ciao ciao

I wonder ... does stripe list anywhere the data field definitions of the various keys?

because I'm seeing cases where the examples show different size keys for the same thing (or what looks like the same thing) For example. I have one acct_ key that has a different length than another one from the example. Like this one stripe_user_id: 'acct_ILdCda3DhGCq0v' has a length of 19

but this one has a length of 21 acct_1B3xNjIN99EayIrI ... so ... um ...

is there a data definition of these keys at all?

or are they just any length?

i am making a variable for stripe and don't know where to place it in my cpanel. Does anyone know which folder?

has anyone ever made a stripe variable button for wordpress?

https://stripe.com/docs/api#account shows an acct_ key with 21, for example. But in this case https://stripe.com/docs/connect/standard-accounts the acct_ key is 19.

hrmmm.

are they two different keys with the same prefix maybe??

hmmm

ok ...confused.

I need to be able to have my clients pay different amounts, not set ones on my site

vbwyrde: stripe IDs are variable length, but guaranteed to be < 255 chars: https://stripe.com/docs/upgrades#what-changes-d...

carl_: if you're still around, stripe.js v2 is fine to use for PII

ah

stripe.js v3 is specifically in response to PCI DSS 3.2, but PII isn't in scope for PCI DSS

but the prefix defines what the key is for then... so there is only one acct_ key and it's used only for one purpose throughout the system. it's not like there are two variables which both have an acct_ prefix... is that right?

the rest of stripe.js v2 functionality should eventually get ported to v3, but it hasn't happened yet

vbwyrde: in practice, I believe that to be true, but I wouldn't rely on that being true

hm

you're never given a bare ID - it always comes with a specific description of what that ID is for

when you say a specific description of what the id is for ... can you give me an example?

per the "what changes does stripe consider backwards compatible" description, you should consider IDs to be opaque strings with no particular format

ie:

when you get a payout object, it has an ID, but it also has an `object` field which has the value "payout"

hm

so you know it's a payout specifically - you don't need to infer that from the payout ID starting with po_***

ok so I guess there is no point in trying to validate that keys are correct based on their format after all

API keys in particular?

well I was doing a IsValidStripeConnectAccountKey when I get the key back to make sure that's valid

but now I see that's a moot point

ie: starts with acct_*?

I was comparing size and starts with acct

yeah

but now I see size is variable, and I have no guarantee that it will start with acct_ either

like, some very old accounts have IDs that start with user_

so ... totally useless effort

and even older ones have UUIDs

if it can ever change then I don't want to use it.

I'll just screw myself up the next time they change the format

so never mind.

I'll do without validating

yeah, that seems reasonable

like, if the API is giving you back mangled data, you're already sort of hosed

I'm not happy with it, but that's the way it is. I prefer to validate before I commit generally. That's kind of SOP for my coding style. No matter. I will live with it.

the other way to do it is to warn when the data doesn't match your expectations

log it somewhere, send yourself an email, generate an error event, whatever

yeah... but I can't have any expections in keys that can change size and prefix

I mean, they change in prefix very rarely

that's not a good thing.

in the last 4 years, I think there have been 2 (citation needed) changes in ID prefix

yeah, better to avoid validation then.

no sense in hosing my code and my users every 2 to 4 years