#charlie-fanbase_api
1 messages ยท Page 1 of 1 (latest)
๐ Welcome to your new thread!
โฒ๏ธ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
โฑ๏ธ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
๐ This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1498676666321473556
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
Hello?
hey there, taking a look
hey thanks, this is the code we use to parse it
response.Data = new FCM.PaymentMethods()
{
CardAvailable = paymentMethods.Data.FirstOrDefault(pm => pm.Application != null).Card?.Available ?? false,
BankTransferAvailable = false, // This is not currently returned by this endpoint but Klarna is not returned correctly by any other endpoint
KlarnaAvailable = paymentMethods.Data.FirstOrDefault(pm => pm.Application != null).Klarna?.Available ?? false,
};
we are getting different results for the Klarna value despite the settings being the same
Can you say more about what you mean here?
From the snippet above, we are getting Klarna = true for some accounts, but not others
despite the payment methods appearing the same in dashboard
It looks like there is multiple configurations being returned, but how are we to know which is correct for the platform?
Can you share some example/trimmed results form these API calls? I am not able to see GET request repsonse bodies
Aye sorry don't have them
What is the application in this data?
Its tricky to know which configruation we are supposed to look at
There can be multiple, this API supports creating many for different scenarios
the application is going to be the connect platform ca_123 ID of the platform that this is set up for
In all cases where a payment method configuration applies, you should be able to specify one by ID, or the default will apply
So filtering this based on Application != null, should return the payment configuration for the connected account?
You might still have multiple, which is why i would like to see the results to understand what you're evaluating
ie, what are the differences
You can also look at the payment_method_configuration on eg payment intents to see what was used, which could be a hint about which one you're interested in looking at
Can you see the dashboard If I send you a link?
I'll try grab the JSON returned
For this account Klarna seems to be enabled for default (which should be where application != null)
But we are unsure of where the Billing Payments configuration has come from? We have never actively created it
acct_1Pgk72DAW7EjbNQ6 is the account id
This was generated automatically to migrate off of separate Billing-specific settings that existed before payment method configurations
It's used for subscriptions/invoices unless you change that in your billing settings
Ok, I think this is what is confusing it, I'm trying to recreate in test environment
How do we filter out the Billing-specific settings when calling get payment methods endpoint?
Application != null, is what we are using, (from code above) but that doesn
t appear to work all the time
Are you use subscriptions/invoice at all via your platform?
Yes we use them both with destination and direct charges
How do we filter out the Billing-specific settings when calling get payment methods endpoint?
I'm unclear what you're getting at here, then. Those will be relevant if you're using these features.
When we list the payment configurations, how do we know which one is for the billing specific settings?
Maybe some additional context will help
we don't store payment configurations anywhere
before PMCs existed, there were some invoice-specific payment method settings in the dashboard
To unify settings, these were migrated to PMCs later, but to avoid breaking changes we could not merge those with the singular default PMCs, so separate Billing PMCs were created and set as the PMC in the billing setttings
if you look at your dashboard billing settings you should see that PMC selected there
Not all accounts will have such a billing-specific PMC, because if they were created afte that migration there is only a singular PMC by default, used by both billing and non-billing cases. A user can still make separate PMCs of course, but its not default behaviour.
We are trying to create a checklout session, in order to know whether to request Klarna, we use the payment method settings to check if it has been enabled via dashboard. The issue is that this endpoint now seems to return multiple configurations, which is tripping up our code, is there a flag in the Stripe SDK we can use to only return the default configuration settings?
in order to know whether to request Klarna
Can you explain a bit more? The point of dynamic payment methods and these settings is to enable payment methods automatically for you when supported for the flow
So, for example, the settings themselves should already automatically enable Klarna without you doing anything
I'm unclear on why you are trying to query the PMC manually to apply manual PM logic
We have a transaction limit and we enable it certain busioness logic scenarios
so like to have control over when it is used
But yes, given this billing PMC migration, some accounts will have multiple PMCs. You can check the is_default property for example to get just the default PMC, but the Billing-specific PMC is signified in API only by its name and by being the setting used in the Billing dashboard settings
Have you seen our support for setting min/max transaction amount rules on payment methods to control functionality like this?
https://docs.stripe.com/payments/payment-method-rules#set-rule-conditions
Ok we will keep control in house for now
So I have result JSON
for this account: acct_1Pgk72DAW7EjbNQ6
There are 2 I can see in the dashboard
But the API is returning 3 sets
Should our logic to get the default settings for connected acount payment methods then be: Application != null && IsDefault == true
Hey sorry are you still here?
Yes sorry, i do see the 3 PMCs, one for the account itself (application=null) and two for your application (one default, one for billing)
You can do this if you only manage that one setting via your platform and not the billing one
Ok, then i would say looking only at the is_default PMC is the way to go
That logic should then get the payment methods as they load on the dashboard? i.e. from the URL https://dashboard.stripe.com/acct_1DvvAXDH4mMwLsQW/connect/accounts/acct_1Pgk72DAW7EjbNQ6/settings/payment_methods
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
And while it's not what we recommend, if you're using manual payment method types on sessions and elsewhere, informed by the PMC, then the other PMC should never come into play
We have others where there are 4 being returned, with more than 1 default, so we will have to use application != null also
Though I would encourage you to test out leaning on the PMCs and letting some of this logic be automated away
yes, sorry, always with application = your platform i meant
its possible for the account to have its own default + billing too
Ok great thanks, out of curiousity when was the backfill / change to this made? We use Klarna only sometimes, but it was working 6 months ago
It's been a while, though it may depend on what happened on the account. My own billing PMC was created 18months ago, for example.
Ok, but at some stage there was a backfill and a lot were created across all accounts? (sorry I need to do a quick write up to explain to my manager what changed)
Also is there a reason this issue doesn't happen in test environments?
Ok, but at some stage there was a backfill and a lot were created across all accounts? (sorry I need to do a quick write up to explain to my manager what changed)
I think there is some activity based trigger here, because I also checked my test platform and some connected accounts to see them created longer ago too.
Also is there a reason this issue doesn't happen in test environments?
It does, though you may not have encountered accounts with this configuration in test/sandbox
If i recall, sandboxes were made public after PMCs and so sandbox accounts will ~never have this split by default, only if a user explicitly creates a separate PMC for billing
(if cloned from an existing account with this pattern they might get a copy of those split PMCs)