#var_dev

1 messages · Page 1 of 1 (latest)

fringe muralBOT
wooden granite
signal cypress
#

I do, in most cases it works, this one is exceptional

#

anything I can provide to help you see the issue?

wooden granite
#

If there is a particular issue with one payment decline

#

you need to reach out to Stripe Support

#

this channel is for technical integration questions

#

And share with them this particular decline

signal cypress
#

there is couple of them but this one is the most vivid

wooden granite
#

Yes feel free to share with them all the declines.

signal cypress
#

so I'd like rather someone technical to tell me if I request MOTO correctly?

#

I follow the docs but maybe I'm missing smth

#

could you at least check the requests please?

#

{
"description": "Booking X",
"payment_method_options": {
"card": {
"moto": "true"
}
},
"metadata": {
"paymentDescription": "Booking X"
},
"customer": "cus_XXX",
"payment_method": "pm_1OhhnzCBeXMSYrP7BgtFEjMR",
"confirm": "true",
"payment_method_types": {
"0": "card"
}
}

#

I see the decline code: "do_not_honor" that comes from the card issuer so I don't think the support will tell me more then: It was declined by the card issuer

#

But maybe I miss some params or I add one that restricts the transactions when I create the PaymentMethod or SetupIntent?

#

and that's my actual question if you could help me with it

wooden granite
#

How are you collecting this PaymentMethod "payment_method": "pm_1OhhnzCBeXMSYrP7BgtFEjMR", ?

#

let me check

#

You need first to initiate a first payment intent with the card details and save it for future usage.

signal cypress
#

do I? You say it's not possible to create a PaymentMethod and add it to SetupIntent flagged as moto without initial PaymentIntent?

#

Element:
const options = {
mode: 'setup',
currency: stripeConfig.currency, // e.g. 'usd'
paymentMethodTypes: ['card'],
paymentMethodCreation: 'manual',
locale: stripeConfig.lang,
} as StripeElementsOptionsMode;
const elements = stripe.elements(options);
const paymentElement = elements.create('payment', {
terms: {
card: 'never',
},
wallets: {
applePay: 'never',
googlePay: 'never',
},
});
paymentElement.mount('#payment-element');

wooden granite
#

Unless I'm missing something, you are not using SetupIntent when collecting that payment method pm_1OhhnzCBeXMSYrP7BgtFEjMR

signal cypress
#

PaymentMethod:
const { error, paymentMethod } = await stripe.createPaymentMethod({
elements: stripeElements,
params: {
billing_details: {
name: htmlspecialchars(cardholderNameContainer.value),
},
},
});

wooden granite
#

Yes you are using the deffered appraoch and createPaymentMethod

#

Why are you using Stripe Element in order to collect the payment method for a MOTO transaction?

signal cypress
#

Step 1. Client-side form to create a PaymentMethod (the code see above)
Step 2. - send Pamyment Method ID to a server
Step 3. Create SetupIntent flagged as moto on a server with params like this:
$params = [
'customer' => $stripeCustomer,
'description' => $stripeDescription,
'metadata' => [
'paymentDescription' => $stripeDescription,
],
'payment_method' => $paymentMethodId,
'payment_method_types' => ['card'],
'payment_method_options' => [
'card' => [
'moto' => true
]
],
'confirm' => true,
];

wooden granite
#

Who is using the Client-side form ? is it your end customer or your employee ?

signal cypress
#

I'm using Stripe Element in order to collect the PM for MOTO because that's what one of your colleagues said that I can do. I asked if I can use Stripe Element to collect card details for MOTO. I was advised to create an element, create a PM and finish the transaction on a server by adding PM to setupIntent flagged as MOTO

#

My end-customer is using the form

wooden granite
#

If your end-customer is using the Form so why you want to use MOTO ?

#

What I'm not understanding is what is the need for MOTO in your case ? while your end customer are using Stripe Element in order to provide their payment methods ?

signal cypress
#

We provide the system for managing bookings. Our customers use our system. They receive booking reservation via Mail, Telephone etc.. so they need a form to add cards and they need MOTO

wooden granite
signal cypress
#

it requires 3DS

#

MOTO doesn't

fringe muralBOT
wooden granite
#

MOTO isn't designed as a workaround for 3DS

#

3DS is something required by the bank issuer

#

and that's may explain the declines you are getting.

signal cypress
#

exactly, so MOTO is for very specific use-cases: MAIL, TELEPHONE

#

it's not workaround - it's using it for the specific cases

cold briar
#

yeah payments that are processed via the dashboard do get processed as MOTO on the backend.

#

I asked if I can use Stripe Element to collect card details for MOTO. I was advised to create an element, create a PM and finish the transaction on a server by adding PM to setupIntent flagged as MOTO
so it's your employee (a call center agent etc) entering the card into Elements? not the end-customer?

signal cypress
#

right, so my problem is that although I flagged my operation as MOTO it din't go through and when the user went to his dashboard he managed to add the same card

#

Answering you questions - thera are 3 parties

#
  1. My company providing saas
  2. Customers using the system
  3. end-customers (clients of my clients)
cold briar
#

so you use MOTO for 2), when someone empoyed at your customer takes some card details from their end-customer and enters them?

signal cypress
#

yes

cold briar
#

cool. So getting back to the issue:

right, so my problem is that although I flagged my operation as MOTO it din't go through
what does that mean precisely, there was some payment that declined or required 3DS that you didn't expect to? if so, what's the ID of that payment or a request ID req_xxx?
Note in any case all you can do is flag the transaction as MOTO, the bank can still choose to ignore that (or have their own problem) and request 3DS.

signal cypress
#

ok, but when the customer goes to his Stripe dashboard he can add the same card manually via the form you provide which is also flagged as MOTO

#

and he can use it

#

so both operations are flagged as MOTO but your works and mine does not

#

so maybe there is an issue on my side

cold briar
#

cool, so show me the example you have that doesn't work and we'll go from there

signal cypress
#

I'm trying to figure out the problem

#

ok

#

do you need a link to logs?

cold briar
#

I need the ID of that payment or a request ID req_xxx

signal cypress
#

declined: req_Tk9qIwvfVdnGmw

#

passed: req_Zk5C8OWTeZPXgB

#

sorry, here is the correct for passed: req_ICKvRlvx9jdHPj

cold briar
#

ok well to be clear that second request ID from the dashboard, actually does nothing with the bank, it's just adding the card with no validation, so it couldn't decline really

signal cypress
#

but then it creates SetupIntent with the card: req_Zk5C8OWTeZPXgB

cold briar
#

in the first request ID, you do everything normal and correct, but the bank declined the $0 validation charge with do_not_honor, which isn't anything you do anything about beyond asking the customer to give a different card.

cold briar
signal cypress
#

so the way I see it: when you add a card via Dashboard MOTO is better enforced for some reasons? The bank didn't decline. But when I created a SetupIntent flagged as MOTO with the same card (paymentMethod) the bank decliend

#

and that's interesting for me - why?

#

maybe I somehow restrict MOTO on my side

cold briar
#

I don't think any of that can be answered really. I don't see this as having anything to do with MOTO whatsoever. It's just the bank declining or not declining the actual authorisation(not connected to authentication)

#

if this is something you're testing in livemode using your own cards etc I wouldn't draw many conclusions from it since it's not a natural pattern and the bank might treat things differently or as fraud

signal cypress
#

it's a real card used by my csutomer

#

live environment

cold briar
#

there's no difference between what you're doing and the Dashboard is doing, the difference is the bank declining or not, and that's something only they can know why

signal cypress
#

ok, then last question that bothers me a bit: when I create a PaymentMethod on a clientside I add a param: currency but I don't add amount. The way I understand the doc currency is required. But when I test test cards everything works. So now I'm wondering -
1.is it required or not?
2. could that influence the way the transaction is verified? e.g. I provide the currency but no amount so the amount defaults to 0 and that's why it's declined..?

cold briar
#

hmm I'm not aware of any currency parameter to the PaymentMethod API, can you show me an example of that?

signal cypress
#

ok, clarification - I add the param currency when creating an Element, sorry for confusion

#

const options = {
mode: 'setup',
currency: 'usd',
paymentMethodCreation: 'manual',
// Fully customizable with appearance API.
appearance: {/.../},
};

// Set up Stripe.js and Elements to use in checkout form
const elements = stripe.elements(options);

// Create and mount the Payment Element
const paymentElement = elements.create('payment');
paymentElement.mount('#payment-element');

#

from the doc

cold briar
#

also the validation that a SetupIntent does(this $0 charge I mentioned) is done in the default currency of the merchant account being used(so it's a 0-euro charge for an IE account and 0-USD for a US account). Sometimes that can lead to declines or issues yes, but it's not something we provide a way to control at the moment

cold briar
signal cypress
#

I see

cold briar
#

in any case in the two examples you shared they were both done in USD as it was a US connected account

#

in any case I can't tell you why any particular charge declined or so on, and I don't see an integration issue here, the code etc seems normal

signal cypress
#

alright, thx a lot for help!