If you've already read about the basic of the GiveCampus API, you may have a few additional questions about certain call parameters. Most can be answered on the API Documentation page, but for everything else, here are some FAQs
If you've already read about the basics of the GiveCampus API, you may have a few additional questions about certain call parameters. Most can be answered on the API Documentation page, but for everything else, we've added some FAQ's below.
API Documentation Site
The site includes:
- Request, result, and data models including field name, type, and description
- A testing tool (using your an API token from your school) to understand the request lifecycle and parameters
- Additional security information
Users must log in to access the information (they do not need to be GiveCampus school admins)
- Username: givecampus
- Password: apiuser
Available documentation pages:
More API FAQs
Here are some additional questions you may have as you begin working with the API.
Can you explain the timestamp options?
The following are plain English explanations of the various timestamps that can be used to query against the GiveCampus API:
confirmed_at (i.e., datetime_of_pledge) - DEFAULT
The confirmed_at timestamp represents when a donor completes the GiveCampus online checkout flow. That said, it doesn't represent when we actually took money out of the donor's bank account, or when a school received the funds.
For example, let's pretend I set up a matching gift on an athletics challenge (e.g., "I will give $5 for every donor who gives to Baseball, up to $1000"). I won't be charged immediately, because my total gift amount is conditionally based on how many other donors give to the campaign. If 30 donors make a gift to Baseball, my matching gift will ultimately get charged $150 at the end of the campaign. My confirmed_at field might be set to February 27th, 4:00pm ET (when I set up my match), whereas the captured_at + deposited_at fields described below might be a few days into the future (when the school's payment processor actually charged my credit card).checkout_at
The checkout_at timestamp represents the moment a school's payment processor initiated a charge against the donor's credit card or bank account. This is when the money leaves the donor's account, but doesn't necessarily represent when it shows up within the payment processor's dashboard, or the school's bank account.captured_at
The captured_at timestamp represents when the donor's money makes its way into the school's payment processor. It hasn't necessarily been deposited into the school's bank account yet.
deposited_at
The deposited_at timestamp represents when a donor's funds are deposited into the school's bank account. Schools can choose to accept daily, weekly, or monthly deposits for Stripe and daily deposits for PayPal.
Can you give an example of how timestamps might differ by payment type?
Example: Credit Cards
For regular one-time credit card transactions, the confirmed_at, checkout_at, and captured_at fields will almost always be within a few minutes of each other. This is by far the most popular type of gift made on GiveCampus. Let's pretend you make a gift to a school using Stripe. As soon as you complete our online checkout flow, Stripe will try to charge your card, and it will quickly appear within the school's Stripe account. That said, the checkout_at + captured_at fields can still be delayed for a few hours/days with credit card gifts, if the donor chose to make a matching gift in a Social Fundraising campaign (like in the first timestamp example for the confirmed_at field).
Example: Bank Gifts (Instant Verification)
Before you can initiate a bank transfer on GiveCampus, you have to prove you're the rightful owner of the bank account in question. If a donor uses Plaid to instantly verify ownership of their bank account (by logging into their online bank during the GiveCampus checkout process), the confirmed_at and checkout_at fields should be within a few minutes of each other. Stripe is able to immediately initiate the bank transfer, but the captured_at field will still be a few days into the future (to account for the extra time it takes for bank transfers to complete).
Example: Bank Gifts (Micro-deposit Verification)
If a donor does not want to login to their bank via Plaid to instantly verify ownership of the account, they can opt to manually verify ownership. They will receive a few pennies in their bank account, and be asked to verify the amounts deposited to prove they have access to the account. confirmed_at will represent the moment they completed the GiveCampus checkout flow, checkout_at will be a few days after that to represent when they verified the micro-deposit amounts, and captured_at will be a few more days after that once the funds land in the school's Stripe account.
For gifts, what are the different payment states?
- Stripe payment states explained
- PayPal payment states explained (Coming soon)
For events, what are the different states?
draft - The event has been created but is not live and able to accept registrations
active - The event is live and able to accept registrations
complete - The event has concluded and is no longer accepting registrations
For events, what are the different payment states?
complete - The registration is complete and payment (if any) confirmed
incomplete - The registration has begun but final checkout and payment (if any) are not complete
payment_processing - The registration is in the process of completing payment
payment_failed - The registration payment failed