#connor_api

1 messages · Page 1 of 1 (latest)

narrow condorBOT
#

đź‘‹ 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/1424888664785162250

đź“ť Have more to share? Add more details, code, screenshots, videos, etc. below.

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

vale wasp
#

hi! looking at this now, gimme just a bit to look some things up

feral patrol
#

When we submit a level3 attribute on PaymentIntent.create, it saves the level3 data attribute on both the PaymentIntent and the resulting Charge (even though the documentation does not say that level3 attribute will be exposed on Charge object)

Will the same occur for amount_details and amount_details.line_items? Or will those only be accessible from the PaymentIntent?

vale wasp
#

which new API are you referring to? is there a guide you're following that you can link me to?

feral patrol
#

It was in response to this email:

Starting October 17, 2025, Visa will apply stricter data monitoring standards as part of their new Commercial Enhanced Data Program (CEDP). Under the new standards, to keep your L2/L3 rates, the "unit_of_measure" field needs to be populated accurately.

The API you’re currently using doesn’t make this field available. We recommend updating your integration to the new Payment Line Items API public preview instead, which lets you customize this field.

What you need to do

1.Update your integration: We recommend using the latest version of the Payment Line Items API to send the "unit_of_measure" field.

2.Adopt a new version header: You'll need to use the version header 2025-04-30.preview or higher for API requests that make use of Payment Line Items.

3.Check your line item data quality: Visa verifies businesses for CEDP based on the quality of the data they submit. Review Visa’s best practices for data quality.

About the Payment Line Items APIAs part of the public preview, we’ve added:The "unit_of_measure" field, which will be required under CEDPThe "commodity_code" field, which is an optional field for L2/L3 programsSupport for line items specific to local payment methods, such as Klarna and PayPal, and the ability to manage them in one placePlease update your integration by October 17 to help maintain your L2/L3 rates

If you have any questions, please contact us from our support site. We’re here to help
vale wasp
#

ok cool... let me dig up an example from when i was testing this a while ago

#

have you tried testing it out yourself yet? i see the example where you passed level3 but i don't see one where you passed amount_details

feral patrol
#

Here's a request using amount_details: req_PTN406hX3KP9Ug

But I didn't see it on the resulting charge

vale wasp
#

i just ran a quick test and i think that amount_details is only saved on the PaymentIntent, but let me double check

#

i know with PaymentIntents you have to expand ["amount_details.line_items"] to see anything so it's possible there's something hidden

feral patrol
#

Exactly, yeah, I was wondering if that would expose it on Charge, too, but my local version of the SDK prevented me from verifying

vale wasp
#

i tried it and got a 400 error so if it exists it's structured differently, but i suspect that it just doesn't exist on that object

#

ok i've double checked the public docs and a few internal docs and experimented with a few ways of trying to retrieve it and so far nothing has worked, so i think it's pretty safe to say it isn't accessible from the charge. is that a problem for your integration? if you can give me some additional context i can try to think through other options for you

#

you should always be able to look up the PaymentIntent from a Charge ID, but i know that's another API call you gotta make (depending on the context)

feral patrol
#

I think that will work ok for us, will just need to shift the retrieval of that data to the PaymentIntent. Thanks for looking!