#tayyab_api

1 messages Β· Page 1 of 1 (latest)

mystic dustBOT
#

πŸ‘‹ 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/1476900200990638150

πŸ“ Have more to share? Add more details, code, screenshots, videos, etc. below.

covert zephyr
chrome shale
# covert zephyr hey there πŸ‘‹ could you share the full error message and the request ID (req_123)...

this is the error: {
"error": {
"message": "Sending credit card numbers directly to the Stripe API is generally unsafe. We suggest you use test tokens that map to the test card you are using, see https://stripe.com/docs/testing. To enable testing raw card data APIs, see https://support.stripe.com/questions/enabling-access-to-raw-card-data-apis.",
"request_log_url": "https://dashboard.stripe.com/acct_1SxB8ICaT5moXT74/test/workbench/logs?object=req_aKpmPJSW8fQLOz",
"type": "invalid_request_error"
}
}

Use test cards to validate your Stripe integration without moving real money. Test a variety of international scenarios, including successful and declined payments, card errors, disputes, and bank authentication. You can also test non-card payment methods and redirects.

covert zephyr
#

thanks

#

that error happens when you try to send raw card data directly to our API rather than tokenising on the client-side

we don't recommend doing this generally, due to the associated security and compliance burden

#

but if your business needs to pass raw card data to Stripe in this way, you can follow the guidance in the support doc linked in the error message, in order to get approval for your account to send raw card data to the API

chrome shale
#

what's the way to tokenize this card if we have to use a new card for making a payment?

covert zephyr
chrome shale
#

Here, the use case is that we as a voice AI platform will be collecting card details from the users on-call using the DTMF input ( using keypad).

#

From that lens, what would be your recommendation.

#

I think payment element has more to do with a static payment link which can be sent to the user via SMS / email. Correct me if I'm wrong.

mystic dustBOT
covert zephyr
#

that's a use case called MOTO (mail order / telephone order), which typically does involve sending raw card details from the server

#

the Payment Element isn't just for static links, but it is a UI component that the customer needs to interact with

#

your account needs approval in order to access the parameter to flag transactions as MOTO

chrome shale
#

what I'm reading in this link is that while creating payment methods & payment intenets, I need pass MOTO as an additional flag ?

covert zephyr
#

so you can use the link on that page to submit a request to our support team to get access to this feature

#

yes exactly - we can share integration documentation once the feature is enabled for you

chrome shale
#

but we get this access as a vendor or do I need to ask my client to get this access for us ?

covert zephyr
#

ah yes, the Stripe account holder will need to submit the request to get access to this feature

chrome shale
#

the platform is PCI-DSS compliant. Can send you documentation if that helps

#

I'll reachout to the AE who is involved in this whole thing from the client's side. I think he should be able to get this approval for the client.

#

Having said that, what docs / proof you need for PCI compliance from our side ?

#

And how do you verify ?

faint holly
#

πŸ‘‹ taking over for my colleague. Let me catch up.

chrome shale
#

okay, from the payments intent API, can you tell me where to pass moto ?

Here's the API

{
"id": "seti_1Mm8s8LkdIwHu7ix0OXBfTRG",
"object": "setup_intent",
"application": null,
"cancellation_reason": null,
"client_secret": "seti_1Mm8s8LkdIwHu7ix0OXBfTRG_secret_NXDICkPqPeiBTAFqWmkbff09lRmSVXe",
"created": 1678942624,
"customer": null,
"description": null,
"flow_directions": null,
"last_setup_error": null,
"latest_attempt": null,
"livemode": false,
"mandate": null,
"metadata": {},
"next_action": null,
"on_behalf_of": null,
"payment_method": null,
"payment_method_options": {
"card": {
"mandate_options": null,
"network": null,
"request_three_d_secure": "automatic"
}
},
"payment_method_types": [
"card"
],
"single_use_mandate": null,
"status": "requires_payment_method",
"usage": "off_session"
}

#

@faint holly , checking if you're there.

faint holly
chrome shale
#

thanks, so I need to first get MOTO enabled for the client. Is there anything else that needs to be enabled for processing payments in our use case?

faint holly
#

not for moto

chrome shale
#

as part of the whole workflow, we also want to setup payment schedules & generate payment links.

faint holly
#

you can use the PaymentMethod generated by the SetupIntent for subscriptions

#

when you say payment links, do you mean Stripe's payment links?

chrome shale
#

yeah, stripe's payment links - but custom to an account with a specific payment amount pre-filled on them.

faint holly
#

but then why do you need Moto?

chrome shale
#

this is a different use-case

#

moto would be needed when we will be accepting card details on-call with the help of DTMF

faint holly
#

I don't think you need anything else, but in all cases you should sync with your AE, they might be able to help you stay in a good place until your GTM