#charlie-fanbase_api

1 messages ยท Page 1 of 1 (latest)

lusty ermineBOT
#

๐Ÿ‘‹ 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.

crimson lodge
#

Hello?

ashen raft
#

hey there, taking a look

crimson lodge
#

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,
};

ashen raft
#

we are getting different results for the Klarna value despite the settings being the same
Can you say more about what you mean here?

crimson lodge
#

From the snippet above, we are getting Klarna = true for some accounts, but not others

#

despite the payment methods appearing the same in dashboard

ashen raft
#

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

crimson lodge
#

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

ashen raft
#

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

crimson lodge
#

So filtering this based on Application != null, should return the payment configuration for the connected account?

ashen raft
#

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

crimson lodge
#

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

ashen raft
#

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

crimson lodge
#

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

ashen raft
#

Are you use subscriptions/invoice at all via your platform?

crimson lodge
#

Yes we use them both with destination and direct charges

ashen raft
#

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.

crimson lodge
#

When we list the payment configurations, how do we know which one is for the billing specific settings?

ashen raft
#

Maybe some additional context will help

crimson lodge
#

we don't store payment configurations anywhere

ashen raft
#

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.

crimson lodge
#

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?

ashen raft
#

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

crimson lodge
#

We have a transaction limit and we enable it certain busioness logic scenarios

#

so like to have control over when it is used

ashen raft
#

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

crimson lodge
#

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

ashen raft
#

Can you share those 3 PMCs?

#

I can look that up for an account too, one moment

crimson lodge
#

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?

ashen raft
#

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)

ashen raft
crimson lodge
#

Ok, yes we don't manage the billing ones at all

#

they are auto created

ashen raft
#

Ok, then i would say looking only at the is_default PMC is the way to go

crimson lodge
ashen raft
#

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

crimson lodge
#

We have others where there are 4 being returned, with more than 1 default, so we will have to use application != null also

ashen raft
#

Though I would encourage you to test out leaning on the PMCs and letting some of this logic be automated away

ashen raft
#

its possible for the account to have its own default + billing too

crimson lodge
#

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

ashen raft
#

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.

crimson lodge
#

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?

ashen raft
#

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)

crimson lodge
#

Ok great

#

thanks for your help, was a long one