Payment Vendor (Stripe) should be in Giving API

[sergeaz]

Related Product
API (Giving)

Is your feature request related to a problem? Please describe.
I'm working on an auditing solution to check parity between Planning Center Giving and Stripe. Anyway..
While Giving API has all kinds of usefulness for a donation properties, it is lacking a way to see the source/vendor. In our case, it would be Stripe.
In PCO Giving web UI, an admin can figure out that this is an electronic donation through Stripe:

1. Label at the bottom ("STRIPE").
2. Little dollar sign points to the particular charge in Stripe Dashboard.
   

Describe the solution you'd like
JSON payload (when viewed in API Explorer) for a particular donation that was done via Stripe should include a property for Vendor (Stripe, Square, or any other current or future electronic donation possibilities).

This will enable custom solutions, while also simplifying the UI.

Describe alternatives you've considered
I have considered scraping the UI, but that is far away from an optimal solution.

Additional context

I have..

• Reviewed the documentation found at https://developer.planning.center/docs
• Searched for previous issues asking for this feature request
• Removed all private information from this issue (credentials, tokens, emails, phone numbers, etc.)
• Reviewed my issue for completeness

[github-actions]

Potentially Related Issues

I found some existing issues that may be related to this one. Please check if any of them address your question before waiting for a response:

🟣 #1416 — Giving API seems to be out of date (Closed)

Summary: User requested API updates to match current Giving features, believing the 2019 API version was outdated. Relates to the new issue as it discusses the general pattern of adding new Giving features to the API that aren't yet exposed.

Key discussion points:

• User was concerned the 2019-dated API was stale and missing features like joint donors and memo field
• Planning Center clarified that 2019 represents the last breaking change, not the last update - features continue to be added without version changes
• Joint donors was acknowledged as a high-priority feature still in planning

Resolution: The issue was a misunderstanding. The API continues to receive feature additions (like the memo field) without version number changes. 2019 only indicates the last breaking change, not API staleness.

🟣 #1408 — Please expose the new donation memo field (Closed)

Summary: Request to expose the donation memo field that existed in the UI but not in the API. Directly parallels the new issue's request to expose vendor/payment source information that's visible in UI but missing from API.

Key discussion points:

• User identified a UI field (memo) that wasn't available via API
• Planning Center added it as a read-only attribute first
• Feature was delivered within 2 weeks of the request

Resolution: Successfully resolved. Planning Center added the memo field to all Donation responses as a read-only attribute, documented at the API docs. This demonstrates their willingness to expose UI-visible fields through the API.

🟣 #1402 — Accessing Additional Data in Giving Stamps (Closed)

Summary: User requested access to stamp data including payment channels (text2give, stripe, mobile app) and stripe payout states. Highly relevant as it directly addresses how to identify Stripe donations, which is part of the new issue's core need.

Key discussion points:

• User wanted to identify donations by source/channel (SMS, mobile app, Stripe, API, batch entry)
• Planning Center added a new 'payment_channel' attribute with values: api, sms, mobile_app, web, admin, other
• For identifying Stripe donations specifically, Planning Center advised checking if donation is NOT part of a batch
• Stripe payout status is covered by the existing 'payment_status' field

Resolution: Partially resolved. Planning Center added the payment_channel attribute to identify donation source (Text2Give, mobile app, etc.). However, for Stripe specifically, they suggested using an indirect method (checking batch membership) rather than a direct vendor/payment processor field. The payment_status field addresses payout states.

---

This comment was generated automatically. If none of these match your issue, no action is needed — a team member will review your issue soon.

[jpletner]

Thanks for the suggestion!

At this time, we don’t explicitly expose Stripe (only payment processor we use) as a vendor on the donation resource. However, unless a donation has an associated batch, it is processed electronically via Stripe. So you can use the presence (or absence) of a related batch as an indicator:

Has associated batch → manually entered / batch donation

No associated batch → processed electronically (Stripe)

You can see the full donation resource details in our API documentation here:
https://developer.planning.center/docs/#/apps/giving/2019-10-18/vertices/donation

Would using the presence of a batch relationship work for your use case? If not, we’d love to better understand what you’re trying to accomplish so we can evaluate whether exposing additional vendor information would be helpful.

Let us know!

[sergeaz]

Thank you for responding. Yes, the API doesn't expose the vendor (Stripe), but the user interface does (see screenshots). On user interface, it would be nice to expose the vendor in a more useful way - to allow filtering by vendor. For example, when I want to filter electronic donations to compare Subsplash vs Stripe, I'm not able to do so because Subsplash is treated as Payment Source - good. However, Stripe is bundled together with cash and checks as payment source = Planning Center.

Long story short, what I'm trying to achieve in the API is more than just Vendor name for electronic donations. Since the Stripe charge ID is already available in Giving UI ("ch_XYZ"), I would find the charge ID useful for an auditing tool I'm working on.
A finance admin can edit a Stripe donation in PCO and change the fund. That's great, but I want to know about it by comparing it to the original ch_xyz payment in Stripe as part of audit. There are other cases that would be enabled by having the "ch_xyz" identifier in addition to amount, fund and other properties of a donation. Perhaps, I'm asking more about "ch_xyz" payment identifier rather than Vendor=Stripe in the API.
Thank you for considering it.

[jpletner]

Thank you for the additional context. This is very helpful, especially understanding the auditing use case.

We discussed this internally, and at this time we are not planning to expose the Stripe charge ID (ch_...) in the Giving API.

That said, there are a couple things that may help with what you are trying to accomplish:

1. Identifying Stripe donations

As mentioned previously, unless a donation has an associated batch, it is processed electronically via Stripe. So the absence of a related batch can be used as an indicator that the donation was processed through Stripe.

2. Linking Stripe charges to Planning Center donations

If you are retrieving data directly from Stripe, the charge metadata should include a planning_center_url. That URL contains the Planning Center donation ID, which you can use to map the Stripe charge back to the corresponding donation in our API.

We understand how direct access to the charge ID in the API could simplify certain workflows, and we appreciate you explaining your use case. While we are not exposing it at this time, feedback like this is helpful as we continue evolving and improving our APIs.

For now, I am going to close this issue, but please feel free to reopen it or start a new conversation if your needs change or if you have additional context to share. We are happy to continue the discussion.

[sergeaz]

@jpletner
Would you, please, clarify "at this time we are not planning"? Was an internal feature request opened? I want to make sure this doesn't go beyond acknowledgement.

For suggested workaround, I have a couple comments.
So, electronic donations via Stripe include the following in the JSON payload:

"relationships": {
  "batch": {
    "data": null
  },
  ...
  "payment_source": {
    "data": {
      "type": "PaymentSource",
      "id": "planning_center"
    }
  }
}

However, in my experience, the absence of a batch is not a reliable guarantee that an electronic donation originated from Stripe.

I assume you have internal access to my organization and can verify this by reviewing donations where the payment source is Subsplash. Here is a sample JSON from such a donation; note that a batch is present:

"relationships": {
  "batch": {
    "data": {
      "type": "Batch",
      "id": "1043"
    }
  },
  ...
  "payment_source": {
    "data": {
      "type": "PaymentSource",
      "id": "4850"
    }
  }
}

In this case, the payment_source corresponds to Subsplash.

According to the Payment Sources documentation, additional payment sources are possible and would presumably follow a similar pattern to Subsplash.

So while I can derive that a donation is likely a Stripe electronic donation by checking:

batch = null
payment_source = planning_center

Even after making that determination about vendor=Stripe (not confident), I still cannot be 100% certain that a specific Stripe donation in Planning Center maps to a specific ch_xyz charge in Stripe. The closest I can get via the API is correlating approximate timestamps between Planning Center and Stripe.

At that point, it may be more reliable to inspect the donation page source and parse the Stripe Dashboard link directly, since it contains the ch_xyz charge ID. We have a case here where UI exposes more useful functionality than API - this is rare!

Lastly, if this improvement will not be implemented, could this issue please be re-opened and closed with reason = not planned per GitHub’s guidelines?: Closing an Issue .

[jpletner]

Thank you for clarifying, that helps.

I do want to clear up one important point: we do not use Subsplash as a payment processor within Planning Center Giving. Stripe is the only electronic payment processor we use.

The only way Subsplash donations can appear in Giving is if they are imported via a batch. In other words:

• Donations with an associated batch → manually entered or imported (including Subsplash imports)
• Donations without an associated batch → processed electronically via Stripe

So you can reliably treat any donation that does not have a related batch as a Stripe-processed donation.

---

Regarding re-opening and closing the issue with a “not planned” reason, that is not our typical process, but I am happy to bring it to the team and discuss how we would like to handle that.

Thanks again for the thoughtful discussion and for explaining your use case. It is genuinely helpful context.