#nickdnk - Card Object
fossil valve
second link
on the card property (which should be a Card object) on the payment method, if its type is card
So either it's outdated or I'm looking at the wrong Card class
main cipher
Ah, gotcha.
fossil valve
trying to avoid that kind of error
I'm assuming this has to do with Wallet not being a class or API resource
main cipher
Oh it's in the API.
main cipher
pm.card
Out[7]:
<StripeObject at 0x10bde2c20> JSON: {
"brand": "visa",
"checks": {
"address_line1_check": null,
"address_postal_code_check": "pass",
"cvc_check": "pass"
},
"country": "US",
"exp_month": 2,
"exp_year": 2026,
"fingerprint": "079oGzlbq04X2Y03",
"funding": "credit",
"generated_from": null,
"last4": "3063",
"networks": {
"available": [
"visa"
],
"preferred": null
},
"three_d_secure_usage": {
"supported": true
},
"wallet": null
}
I just pulled this out in my test account
main cipher
Oh, no I don't think that has ever been the case.
fossil valve
Hence my question; is this why it cannot be represented in the PHPDoc?
Because it has no corresponding class
When this was generated manually we would just input mixed as the property type
because then at the very least it would be part of the autocomplete
But now since the PHPDocs come from OpenAPI specs, I assume this won't work for whatever reason
Disclaimer: I've been involved in the php library a fair bit so if you haven't this might not sound familiar
main cipher
Yeah I haven't and am only notionally familiar with the Docs team protocols either.
So you cannot have the wallet exist on the Card if it does not exist as an API resource?
fossil valve
I'm guessing that's why
But just wanted to make sure that this was "working as intended"
main cipher
And that is some restriction of the PHP language itself?
fossil valve
No, not at all.
But the way the PHP library was designed might be the reason that these objects don't exist
Just as a design choice
main cipher
Ah okay.
fossil valve
Because it's a significant amount of maintenance to keep updated
I think the most base resource we have is StripeObject which I believe represents an API resource
i.e. it has REST-y behavior
which does not apply to wallet or similar objects
main cipher
Oh, so you cannot inherit from that class if you don't have an endpoint
fossil valve
Yeah
If I'm not mistaken
I think it's based on traits, but yeah, that's the gist of it
wide marsh
👋
fossil valve
it's pretty easy to solve but requires that someone compiles all of these objects manually
Hey koop
wide marsh
Card is /v1/customers/:id/sources. Completely unrelated to PaymentMethod
you're mostly mixing up your objects I assume but you type fast and that was a lot of words to skim :p
fossil valve
Alright, but there's only one Card class in the PHP library
wide marsh
Yes that's expected. Card is https://stripe.com/docs/api/cards/object
we don't have PHP classes for hashes. We only have classes for API Resources. So the card hash on PaymentMethod is not a class and has nothing to do with the Card class
fossil valve
That's what I expected
I just wanted to make sure that was right
because while you say it's not the same resource, it does have a lot of properties in common
I'll just suppress the warnings. I can imagine that you have no intention of bringing all possible hashes into the library as objects.
I could just create the ones I use the most in my own project and typecast the phpdoc for autocomplete etc. Might be a good middle-ground.
wide marsh
Correct, we don't have plans to change this beyond the top-level phpdocs that you started which we now automatically generate