stripe.charge.list missing metadata

[sirhoe]

When I called
stripe.charges.list(filter, callback);

I get a full list of charges complete with metadata.

However, when i call
stripe.charges.list(filter, {stripe_account: accountId}, callback);

to get a subset of charges from the managed account, I am getting the charges without the metadata.

How can I get the metadata in the second example?

[matthewarkin]

Are you doing charges with destinations where you are creating the charge in the platform account with metadata?

[matthewarkin]

Are you doing charges with destinations where you are creating the charge in the platform account with metadata?

[sirhoe]

Yes, you are right. We are dealing with all managed accounts so all charges has destination set.

FYI, I am able to see the metadata for the charges in the Stripe Dashbboard and I also able to get it via the cURL call. It is just missing when I do stripe.charges.list(filter, {stripe_account: accountId}, callback);

[sirhoe]

Yes, you are right. We are dealing with all managed accounts so all charges has destination set.

FYI, I am able to see the metadata for the charges in the Stripe Dashbboard and I also able to get it via the cURL call. It is just missing when I do stripe.charges.list(filter, {stripe_account: accountId}, callback);

[matthewarkin]

So what you're seeing when you do the send call (the one with stripe_account) is not the charge object but rather the payment object (the charge is in your account, a transfer is created from your account to the managed account, and in the connected account they have a payment). Information like metadata, description, etc isn't copied from the charge to the payment.

One way around this is to either call the update charge api on the payment object, or instead of "charging through the platform", you can "charge directly" where you set the stripe_account header when you create the charge instead of setting the destination

[matthewarkin]

So what you're seeing when you do the send call (the one with stripe_account) is not the charge object but rather the payment object (the charge is in your account, a transfer is created from your account to the managed account, and in the connected account they have a payment). Information like metadata, description, etc isn't copied from the charge to the payment.

One way around this is to either call the update charge api on the payment object, or instead of "charging through the platform", you can "charge directly" where you set the stripe_account header when you create the charge instead of setting the destination

[sirhoe]

@matthewarkin Thanks for the advice but I must 'charge through the platform' to apply application fee and use managed account.

Base on your explanation, I will try to expand on the charge id and see what I get.

Will report back.

---

UPDATE: It doesnt work. I was expecting the returned objects has a charge id which I can expand on but they dont. Essentially they are all payment objects returned as charge object because their id start with 'py_' instead of 'ch_' when you call the same api without the {stripe_account: accountId}

I think this qualifies as a bug. We called charge list and we got payment back.

[sirhoe]

@matthewarkin Thanks for the advice but I must 'charge through the platform' to apply application fee and use managed account.

Base on your explanation, I will try to expand on the charge id and see what I get.

Will report back.

---

UPDATE: It doesnt work. I was expecting the returned objects has a charge id which I can expand on but they dont. Essentially they are all payment objects returned as charge object because their id start with 'py_' instead of 'ch_' when you call the same api without the {stripe_account: accountId}

I think this qualifies as a bug. We called charge list and we got payment back.

[sirhoe]

@matthewarkin can you elaborate on " call the update charge api on the payment object"? How is it done?

[sirhoe]

@matthewarkin can you elaborate on " call the update charge api on the payment object"? How is it done?

[sirhoe]

Found a workaround that is undocumented.

    var filter = {
    destination: accountId
};
    stripe.charges.list(filter, callback);

Now I need Stripe to confirm this won't be suddenly removed :)

[sirhoe]

Found a workaround that is undocumented.

    var filter = {
    destination: accountId
};
    stripe.charges.list(filter, callback);

Now I need Stripe to confirm this won't be suddenly removed :)

[matthewarkin]

You do not need to charge through the platform to use the application fee. Doing stripe.charges.create({charge data}, {stripe_account: "acct_") will work fine even with an application fee. See: https://stripe.com/docs/connect/payments-fees#charging-directly

You cannot expand objects that exist in other accounts.

As to that filter you're doing, its a bit different than doing stripe.charges.list(filter, {stripe_account: "acct_"})

When you charge through the platform the process in how to get funds from the customer to the managed account gets a bit complicated in that the customer is not paying the merchant directly. As such the actual charge is in your account (with all the details you care about) and the managed account just gets a hold of a payment object (these have py_ ids), that are like a subclass of charges (in that they'd appear in the list charges API).

If you wanted to update the payment object with metadata or a description, you'd update it like any charge but with the payment id and stripe_account header: stripe.charges.update("py_", data, {stripe_account:"acct_"})

Generally I'd recommend storing the charge id and account id for each charge in your database than trying to use Stripe as the database

[matthewarkin]

You do not need to charge through the platform to use the application fee. Doing stripe.charges.create({charge data}, {stripe_account: "acct_") will work fine even with an application fee. See: https://stripe.com/docs/connect/payments-fees#charging-directly

You cannot expand objects that exist in other accounts.

As to that filter you're doing, its a bit different than doing stripe.charges.list(filter, {stripe_account: "acct_"})

When you charge through the platform the process in how to get funds from the customer to the managed account gets a bit complicated in that the customer is not paying the merchant directly. As such the actual charge is in your account (with all the details you care about) and the managed account just gets a hold of a payment object (these have py_ ids), that are like a subclass of charges (in that they'd appear in the list charges API).

If you wanted to update the payment object with metadata or a description, you'd update it like any charge but with the payment id and stripe_account header: stripe.charges.update("py_", data, {stripe_account:"acct_"})

Generally I'd recommend storing the charge id and account id for each charge in your database than trying to use Stripe as the database

[brandur]

@matthewarkin As usual, thanks a lot for assist here! Excellent advice.

@sirhoe It sounds like you got your issue resolved, so I'm going to close this out for now.

Now I need Stripe to confirm this won't be suddenly removed :)

Unfortunately, given that it's not in the documentation yet, we can't absolutely commit to the API stability of this parameter. That said, I don't think there are any initiatives to remove it either.

[brandur]

@matthewarkin As usual, thanks a lot for assist here! Excellent advice.

@sirhoe It sounds like you got your issue resolved, so I'm going to close this out for now.

Now I need Stripe to confirm this won't be suddenly removed :)

Unfortunately, given that it's not in the documentation yet, we can't absolutely commit to the API stability of this parameter. That said, I don't think there are any initiatives to remove it either.

[brandur]

Just a quick follow up to my original comment: after some discussion internally, I think we will be able to commit to supporting the destination parameter. It won't be official until it's in the documentation, but changes there are forthcoming.

[brandur]

Just a quick follow up to my original comment: after some discussion internally, I think we will be able to commit to supporting the destination parameter. It won't be official until it's in the documentation, but changes there are forthcoming.

[thebigredgeek]

@brandur any update here? A bit nervous about using this parameter, but I need to be able to pull charges by their destination :(

[thebigredgeek]

@brandur any update here? A bit nervous about using this parameter, but I need to be able to pull charges by their destination :(

[sirhoe]

@thebigredgeek I would suggest you to open a new ticket and reference this one to get better attention. Closed tickets are harder to notice by the support team.

Just my IT 2 cents. :)

[sirhoe]

@thebigredgeek I would suggest you to open a new ticket and reference this one to get better attention. Closed tickets are harder to notice by the support team.

Just my IT 2 cents. :)

[fred-stripe]

@sirhoe that's not needed actually; in fact, please don't. 😃 Many people at Stripe subscribe to all activity across the official Stripe libraries so creating duplicate issues can make it tough for us to track what's going on. Also, anyone subscribed to the original issue would not be subscribed to the new one.

Sorry that you've had to wait for an answer on this @thebigredgeek; we're still working out the details of documenting the destination filter parameter and making it officially supported. For now, go ahead and use the parameter, and if anything changes we'd contact you directly or make an announcement on the API Discussion Mailing List. In the case that the destination parameter is removed for any reason, you would not be the only person affected, and we'd make an effort to contact everyone using that parameter, as well as a provide a replacement. Sound like a plan?

[fred-stripe]

@sirhoe that's not needed actually; in fact, please don't. 😃 Many people at Stripe subscribe to all activity across the official Stripe libraries so creating duplicate issues can make it tough for us to track what's going on. Also, anyone subscribed to the original issue would not be subscribed to the new one.

Sorry that you've had to wait for an answer on this @thebigredgeek; we're still working out the details of documenting the destination filter parameter and making it officially supported. For now, go ahead and use the parameter, and if anything changes we'd contact you directly or make an announcement on the API Discussion Mailing List. In the case that the destination parameter is removed for any reason, you would not be the only person affected, and we'd make an effort to contact everyone using that parameter, as well as a provide a replacement. Sound like a plan?

[domahub]

Was there any update on making the destination parameter officially supported?

[domahub]

Was there any update on making the destination parameter officially supported?

[fred-stripe]

No update yet. Please watch the API Discussion Mailing List for news on this. Thanks!

[fred-stripe]

No update yet. Please watch the API Discussion Mailing List for news on this. Thanks!

[praboud-stripe]

To close the loop here, we've decided to remove this undocumented parameter.

You should be able to do something roughly equivalent by listing transfers to the destination account, and expanding the charge that is the source_transaction. (If you create transfers directly, this query will include both these transfers as well as transfers created as part of the destination charge. You'd need to filter the first type out on the client side by ensuring that transfer.source_transaction.transfer == transfer.id if you need exactly the same behaviour as before.)

We'll be reaching out to the accounts currently using this parameter to let them know it's going away but I wanted to flag this here. We'll provide a more detailed timeframe for turning this off, but our current plans are to remove the parameter completely on May 10th.

[praboud-stripe]

To close the loop here, we've decided to remove this undocumented parameter.

You should be able to do something roughly equivalent by listing transfers to the destination account, and expanding the charge that is the source_transaction. (If you create transfers directly, this query will include both these transfers as well as transfers created as part of the destination charge. You'd need to filter the first type out on the client side by ensuring that transfer.source_transaction.transfer == transfer.id if you need exactly the same behaviour as before.)

We'll be reaching out to the accounts currently using this parameter to let them know it's going away but I wanted to flag this here. We'll provide a more detailed timeframe for turning this off, but our current plans are to remove the parameter completely on May 10th.

[thebigredgeek]

I think that's a great choice. Private by default is a really solid convention to follow ;)

[thebigredgeek]

I think that's a great choice. Private by default is a really solid convention to follow ;)

[sirhoe]

Ouch.

@praboud-stripe while I understand and accept the changes, I would like to request for more time to implement the changes on our end. 10th May is less than 1 month away and our business prefer to group our changes to production on a planned quarterly basis.

Can I make a request to postpone the doomsday to somewhere in July?

Cheers.

[sirhoe]

Ouch.

@praboud-stripe while I understand and accept the changes, I would like to request for more time to implement the changes on our end. 10th May is less than 1 month away and our business prefer to group our changes to production on a planned quarterly basis.

Can I make a request to postpone the doomsday to somewhere in July?

Cheers.

[praboud-stripe]

@sirhoe: unfortunately, we're unable to continue to support this parameter until July. More generally, we don't provide stability guarantees for undocumented features, because they're not intended for public use.

(Separately, I misspoke before - the cutoff date will actually be May 11th.)

[praboud-stripe]

@sirhoe: unfortunately, we're unable to continue to support this parameter until July. More generally, we don't provide stability guarantees for undocumented features, because they're not intended for public use.

(Separately, I misspoke before - the cutoff date will actually be May 11th.)

[ritterb82]

A couple followup questions on this.

In the Stripe Dashboard. If you go to connect -> connect transfers -> click on the transfer you want the dashboard shows a charge transaction. "source txn"

Questions / Issues

1. When you use the STRIPE.transfers.list function, that charge data is not returned. So there is no way to get the meta data (such as description of the charge)
2. Let's say it is returned, is there a way to get that data expanded so that it doesn't require a second call to get it?

The use case here, is connect platform where all the charges are made through the platform using the destination parameter on the charge. Then for each connected account I want to show the charge history FOR THE CONNECTED ACCOUNT. Currently, it seems the best I can do is get the transfers, but then I have no way to get the actually charge data such as meta and description.

Am I missing something here? What endpoints should be used to basically generate a transaction history with charge meta data?

(the suggested "workaround" that is not supported, actually seems like its the simplest approach and actually achieves the desired result)

[ritterb82]

A couple followup questions on this.

In the Stripe Dashboard. If you go to connect -> connect transfers -> click on the transfer you want the dashboard shows a charge transaction. "source txn"

Questions / Issues

1. When you use the STRIPE.transfers.list function, that charge data is not returned. So there is no way to get the meta data (such as description of the charge)
2. Let's say it is returned, is there a way to get that data expanded so that it doesn't require a second call to get it?

The use case here, is connect platform where all the charges are made through the platform using the destination parameter on the charge. Then for each connected account I want to show the charge history FOR THE CONNECTED ACCOUNT. Currently, it seems the best I can do is get the transfers, but then I have no way to get the actually charge data such as meta and description.

Am I missing something here? What endpoints should be used to basically generate a transaction history with charge meta data?

(the suggested "workaround" that is not supported, actually seems like its the simplest approach and actually achieves the desired result)

[remi-stripe]

@ritterb82 When we released the latest API version, 2017-04-06, we removed the source_transaction property which is why you can't get to it anymore. You need to use the List Charges API and pass the transfer_group value on the Transfer in the transfer_group parameter to get the list of charge(s) that were part of this Transfer. This feature has been asked a lot though and we're working on bringing it back, hopefully over the next few weeks.

In the meantime, you can force an earlier API version and use the Expand feature to get everything in one API call.

[remi-stripe]

@ritterb82 When we released the latest API version, 2017-04-06, we removed the source_transaction property which is why you can't get to it anymore. You need to use the List Charges API and pass the transfer_group value on the Transfer in the transfer_group parameter to get the list of charge(s) that were part of this Transfer. This feature has been asked a lot though and we're working on bringing it back, hopefully over the next few weeks.

In the meantime, you can force an earlier API version and use the Expand feature to get everything in one API call.

[fred-stripe]

@ritterb just a quick update: as of today the source_transaction property has been restored on Transfer object, so you can go back to expanding the original transfer while retrieving charges as before.

Keep in mind that if you're using transfer groups, there still can be more than once transfer linked to a single charge, so you'll want to take that into account.

[fred-stripe]

@ritterb just a quick update: as of today the source_transaction property has been restored on Transfer object, so you can go back to expanding the original transfer while retrieving charges as before.

Keep in mind that if you're using transfer groups, there still can be more than once transfer linked to a single charge, so you'll want to take that into account.

[ritterb82]

@fred-stripe Thanks for the update! Excellent!

[ritterb82]

@fred-stripe Thanks for the update! Excellent!

[kire73]

Different issue, same topic. Please let me know if I should post somewhere else.

I use the metadata fields to store information about subscriptions that are created with existing plans through the API. When retrieving charges, I match the metadata, which works well for all charges except subscription charges. I assign the metadata when creating the subscription, but the plan has none since it varies, and it seems the metadata is carried from the plan to the charge, rather than from the subscription it was charged under. Is there another way to dynamically assign metadata to subscription charges?

I can pull this info from the invoice, but it would mean sending multiple requests since not all of my charges are invoiced. Any help is appreciated!

[kire73]

Different issue, same topic. Please let me know if I should post somewhere else.

I use the metadata fields to store information about subscriptions that are created with existing plans through the API. When retrieving charges, I match the metadata, which works well for all charges except subscription charges. I assign the metadata when creating the subscription, but the plan has none since it varies, and it seems the metadata is carried from the plan to the charge, rather than from the subscription it was charged under. Is there another way to dynamically assign metadata to subscription charges?

I can pull this info from the invoice, but it would mean sending multiple requests since not all of my charges are invoiced. Any help is appreciated!

[remi-stripe]

@kire73 Those questions are better for our support team. You can contact them here. The issues on this repo are here to report bugs with the library itself.

While I'm here though, there's no way to automatically put the subscription's metadata on the charge. You can either expand the subscription details from the charge by going through the invoice or you'd update the charge after its creation (listening to webhooks) so that it reflects the right metadata.

[remi-stripe]

@kire73 Those questions are better for our support team. You can contact them here. The issues on this repo are here to report bugs with the library itself.

While I'm here though, there's no way to automatically put the subscription's metadata on the charge. You can either expand the subscription details from the charge by going through the invoice or you'd update the charge after its creation (listening to webhooks) so that it reflects the right metadata.