#Zachary_DuBois

1 messages · Page 1 of 1 (latest)

scenic jettyBOT
cloud yew
#

Hi 👋

Can you share the documentation you are working off of?

slim dock
cloud yew
#

And what part of this is not happening as you expect?

slim dock
#

It isn't really documented but with the old ACH credit transfers, the customer account was assigned bank account information that they could send any amount to and it would reconcile against any open intents that it would cover

#

With this, I created a payment intent tied to a customer that hasn't used bank transfers before, and it appears that the bank account is only available on the payment intent, not the customer.

# 
$paymentIntent = $stripe->paymentIntents->create([
  'amount' => 10099,
  'currency' => 'usd',
  'customer' => 'cus_O4iZVM29ukRml0',
  'payment_method_types' => ['card','link','afterpay_clearpay','customer_balance'],
  'payment_method_data' => [
    'type' => 'customer_balance',
  ],
  'payment_method_options' => [
    'customer_balance' => [
      'funding_type' => 'bank_transfer',
      'bank_transfer' => [
        'type' => 'us_bank_transfer',
      ],
    ],
  ],
  'confirm' => true,
]);
#

This is what I have now - I am not sure the purpose of "payment_method_data" key in this case

#

I also was wondering why the payment elements when rendering a payment intent like this requires an email (even if the customer has one already saved) to be endered for viewing the bank transfer information

cloud yew
#

First, are you saying you don't see this behavior:

The first time you accept a bank transfer payment from a customer, Stripe generates a virtual bank account for them, which you can then share with them directly. All future bank transfer payments from this customer get sent to this bank account.

slim dock
#

So it might be behaving like that but it doesn't list it under the customer in the dashboard. For example, with the old ACH credit source, it would show ACH credit as a source on the customer and their balance separate. With this new one, it only ever shows the payment information via the payment intent

#

Sec - I can get screencaps

cloud yew
#

That's okay.

#

The "old" approach is a legacy public Beta program so I am not surprised we don't see feature parity

slim dock
#

Yeah, but I would still expect the VBAN to associate on the customer as a source.

cloud yew
#

I can request it but I think that we would suggest you use Stripe Financial Connections as a more future proof approach

slim dock
#

Can you provide some insight to the other questions I had of my specific code snippet where I have multiple payment methods?

#

Like the payment_method_data.type = customer_balance when used with other payment methods

#

(it is working right now, so I don't really care other than I want to understand it so I can keep the logic in my head)

cloud yew
#

If the user selects other payment methods this will get ignored. This data is used to create a new Payment Method.

slim dock
#

But what does it specifically control? Sorry, the documentation is not clear on why this parameter is required.

#

All I know is if it is omitted, I get a payment_intent_unexpected_state error.

cloud yew
#

An additional hash is included on the PaymentMethod with a name matching this value. It contains additional information specific to the PaymentMethod type.

slim dock
#

Ok - I still am not sure why the type key is required only for the customer_balance method. As for the email form using payment elements?

#

The customer has an associated email already. Is there a way to pre-fill this or even provide instructions?

# 
{
  "id": "cus_O4iZVM29ukRml0",
  "object": "customer",
  "address": null,
  "balance": 0,
  "created": 1686670072,
  "currency": null,
  "default_source": null,
  "delinquent": false,
  "description": "testing",
  "discount": null,
  "email": "zdubois@xxxxxxx.com",
  "invoice_prefix": "FD1BC762",
  "invoice_settings": {
    "custom_fields": null,
    "default_payment_method": null,
    "footer": null,
    "rendering_options": null
  },
  "livemode": false,
  "metadata": {},
  "name": null,
  "next_invoice_sequence": 1,
  "phone": null,
  "preferred_locales": [],
  "shipping": null,
  "tax_exempt": "none",
  "test_clock": null
}

For example, this is the customer that is tied to the payment intent in the screencap

cloud yew
#

I still am not sure why the type key is required only for the customer_balance method.
That's what the API requires 🤷‍♂️

slim dock
#

Anything on the above

cloud yew
#

I'm trying to check our logic and internal docs. My first intuition is that we require the customer to be able to provide an updated email.

slim dock
#

Ok - I noticed it does not actually update the customer's email on the customer object if I put something different there (or use a customer object that does not have an email set)

cloud yew
#

No, that's not the intent from what I can see

#

It specifically determines the email address that will be used to send funding instructions

scenic jettyBOT
slim dock
#

So that is weird because when I create the payment intent, it does fire off that email already (which I do not like)

#

Even before displaying with the payment elements

cloud yew
#

When you create your payment element do you specify the email address?

#

e.g.

var paymentElement = elements.create('payment', {
    defaultValues: {
        billingDetails: {
          email: "test@gmail.com",
        }
      },
});
slim dock
#

I did not - let me give that a shot

#

sec

#

Actually, can this be specified on the payment intent under billing_details instead of the element

cloud yew
#

I don't believe so

dusky pike
slim dock
#

No - you can specify it on the payment intent creation from the looks of it

slim dock
#

Still isn't pre-filled

dusky pike
#

Taking a step back, reading through where we started here, what exactly are you trying to achieve as an end state here?

#

I see some discussion of migrating from ACH CT Sources to US Bank Transfer PMs

#

But it's unclear how we got to the email address here

scenic jettyBOT