#nielsen_api

1 messages · Page 1 of 1 (latest)

hazy summitBOT
#

👋 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/1372657661971005601

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

delicate patrol
#

I will add to the feature request around this, but that is where our APIs capabilities are now

lament pike
#

how can I check the fingerprint without adding it first? I ask because I have been told we get charged for every payment method created.

delicate patrol
lament pike
#

I'm guessing this is just for the client side? It requires sending the credit card details through this call right?

delicate patrol
#

You can call it and pass it the payment element and it will collect the details similar to how it does when confirming. So your PCI compliance requirements would stay the same

#

Also I don't know much about fees but am not finding info on a fee per payment method creation from Stripe. I definitely could be missing something, but it may be worth it to double check on that on your end.

lament pike
#

Yea I don't know if this is some contract specific thing my company has but I'm told it's $0.75 per created bank account

hazy summitBOT
lament pike
#

The confirmation token, doesn't create the payment method then?

#

What does it return?

delicate patrol
#

Ah gotcha, that may be financial connections related (again no expert there). FC would be run before the confirmation token is created, so I'm not sure how that would effect your situation.
It returns a ConfirmationToken object, they are meant to store the details temporarily for inspection or if you want to confirm them somewhere else. So you can create the confirmation token, check its fingerprint, and then call confirm with the confirmation token instead of the payment element to attempt to confirm the seutp intent.

lament pike
#

Ok I see, thank you. I'll take this information and contact our account rep to see if this method will avoid the fee

#

One more question

obsidian viper
#

Sure!

lament pike
#

We also create payment methods directly from our backend service. We send you the details securely through a proxy. We use the PaymentMethod API directly. Is there a way to accomplish the same thing using that?

obsidian viper
#

Taking a look

#

What are you really trying to achieve here? Are you saying that you already have the payment method details and then you'd want to create the payment method on server side, then use it to create a payment? You initially asked if you can omit using SetupIntents, and the you switched. I want to ensure that I fully understand your ask/ flow before making any recommendations.

lament pike
#

Yes, I apologize for that, I just remembed that we have 2 flows for adding payment methods. In both, we create a payment method in Stripe and then create our own payment method that references the Stripe one.

#

One is a flow from a web app, and the other is a flow from a automated phone system

#

both flows need to be able to not have duplicate payment methods.

#

We normally have been able to do this by first created the payment method, and once we see that the fingerprint is the same, we detach

#

but it looks like this cause a charge

obsidian viper
#

At this instance, 'payment method in Stripe', with the above flow my teammate suggested you can use the confirmation token to look at the fingerprints

lament pike
#

Does the PaymentMethod api, support confirmationTokens too?

obsidian viper
#

Can you reword that please?

#

Instead of creating the payment method, you would use the confirmation token

lament pike
#

How would I do that from the backend?

obsidian viper
#

You're creating the 'payment method in Stripe' so instead of using the back end to create the payment method. You need use confirmation token on the client-side.

lament pike
#

ah there in lies the issue for us then. We don't have a client side for the automated phone system

#

The client is just a system that calls our servers directly and our servers then relay the payment details to Stripe

obsidian viper
lament pike
obsidian viper
#

You stated 'We don't have a client side for the automated phone system'

#

so it sounds like there is not client system to input that payment method data no?

#

Let's step back. What do you want your flow to look like? How are you collecting these payment method details?

lament pike
#

The "client" is a customer that sends us the card details through our rest api

obsidian viper
#

But there has to be a place where you take that data to make that request no?

lament pike
#

yes, but it's not in our control.

The client or customer has an automated phone system that collects the payment details. This system then takes that data and sends it directly to our servers. Our servers then relay that to Stripe.

hazy summitBOT
lament pike
#

This flow relies on the client not knowing anything about Stripe

obsidian viper
#

How are you passing that on the server side? Just creating a payment method object on the server-side by passing the card payment method details?

#

I need to fully understand your exact flow end-to-end to ensure that my recommendation is what would solve your use case

lament pike
#

so, we get a request with the credit card details(encrypted). We take those details and pass them to Stripe through our proxy, which decrypts the details before sending to Stripe.
Then from the response we get from Stripe, we create a payment method in our database with a reference to the stripe payment method id.

wary garnet
#

👋 Hi there - I'll be stepping in for pgskc, who had to step away

#

Would it be possible to have a look at an example of the output you get from this? As in, what you receive from Stripe? I assume you're talking about a pm_123 object

#

And, to be clear, you're just asking about how you can avoid creating duplicates given the above flow, right?

lament pike
#

yes

#

Effectively we just get the normal output from this call

Stripe.apiKey = "sk_test_BQokikJOvBiI2HlWgH4olfQ2";

PaymentMethodCreateParams params =
PaymentMethodCreateParams.builder()
.setType(PaymentMethodCreateParams.Type.US_BANK_ACCOUNT)
.setUsBankAccount(
PaymentMethodCreateParams.UsBankAccount.builder()
.setAccountHolderType(
PaymentMethodCreateParams.UsBankAccount.AccountHolderType.INDIVIDUAL
)
.setAccountNumber("000123456789")
.setRoutingNumber("110000000")
.build()
)
.setBillingDetails(
PaymentMethodCreateParams.BillingDetails.builder().setName("John Doe").build()
)
.build();

PaymentMethod paymentMethod = PaymentMethod.create(params);

#

We take the paymentMethod, and create our own payment method. Let me see if I can share a request id

#

Here is a request ID
req_T6jSzITiRbIUj6

#

When that call returns, we deserialize the response as a PaymentMethod

wary garnet
#

That's great - thank you - so is req_T6jSzITiRbIUj6 being made by the proxy you were describing?

lament pike
#

Correct

#

so a more complete flow is.

client calls our backend servers
servers redirect call to secure proxy for cc detail encryption
proxy calls our servers with encrypted details
our server calls the proxy again with stripe api endpoint
proxy decrypts details and forwards to stripe
stripe responds to proxy
proxy returns the response to us
we handle it accordingly

wary garnet
#

When you create the Payment Method, does the Customer already exist and you just attach afterward, or do you create and attach after creating the PaymentMethod

lament pike
#

The customer already exists and we attach after

wary garnet
#

I think your ideal state would be that Stripe returned a 4xx if a Payment Method with identical details already exists - not uncommon - but unfortunately our APIs don't work that way. So you would have to do some logic at some point before creating the Payment Method if you want to avoid duplicates before creation.

I think an approach would be to call the "List a Customer's Payment Methods" endpoint, look at the output and compare the details you have with what already exists for the Customer in Stripe and make a determination on if you think its the same card

lament pike
#

Yea that's more or less what we do now.

#

We store the fingerprint in our database and that's how we know there is duplicates

#

but we have to first create it in Stripe to find that

wary garnet
#

Exactly

#

I don't see a way around that here

lament pike
#

Ok, that's fine for now. I'll go back to my team and let them know what is possible and not.

#

Thank you for all the help