Get started

Go-live checklist

Build with AI

Everything to check before your integration handles real donations, and what changes between the sandbox and live: hosts, credentials, payments and webhooks.

Your integration works on the sandbox. Go through this list before the first real donation. Nothing you created on the sandbox exists on live: selections, campaigns and webhooks are created again there.

Each item says who can check it: your coding agent with read-only calls to the live API, your coding agent reading your code, or a person. Tick what is done; the prompt at the end of the page hands the rest to your agent.

Your account

• The account is validated.

  Its onboarding is finished. Until then, creating a token answers 403 Account not active.
  Agent check

  GET /v1/accounts/{accountId} answers status: VALIDATED. GET /v1/accounts lists the accounts your credentials can read, so you do not need the id in advance.Callsget-accountlist-accounts

• The live account has an active subscription.

  Without one, activating a campaign answers 402 NO_ACTIVE_SUBSCRIPTION. Plans and prerequisites
  Manual

  In the dashboard billing settings. GET /v1/accounts/{accountId}?includeBillingInfo=true shows the plan in billingInfo.plan and the next billing date in billingInfo.nextBillingAt, not whether the subscription is active.Callsget-account

• A payment method is on the account that pays.

  That is your account or on each child account if donations must be billed by Charitips directly to your business customers. Without one, donations answer 402 Missing payment method.
  Agent check

  GET /v1/accounts/{accountId}/payment-methods on the paying account lists at least one method with status: ENABLED.Callsget-payment-methods

• Your plan has the features your flow uses.

  API access for webhooks, the B2C use case when your users pay, the account hierarchy feature for child accounts. A missing one answers 402 Plan upgrade required, or 403 for the B2C settings. Plans and prerequisites
  Agent check

  GET /v1/accounts/{accountId}/entitlements answers true for each feature your flow uses, against the flow-by-flow list of Plans and prerequisites: apiAccess for webhooks, b2c when your users pay, accountHierarchy for child accounts.Callsget-entitlements

Credentials and hosts

• Live credentials are in your server's secrets.

  Live client ids and secrets start with live_. They never go in a web page, a mobile app or a repository.
  Code review

  The values of CHARITIPS_CLIENT_ID and CHARITIPS_CLIENT_SECRET in the live environment start with live_, checked without printing them; no live_ or test_ value appears in the repository, a web bundle or a mobile app.

• Every call goes to api.charitips.com, and every widget to embed.charitips.com.

  A live_ pair sent to the sandbox, or a test_ pair sent to live, answers 401 Invalid credentials.
  Agent check

  The live configuration names api.charitips.com and embed.charitips.com and no sandbox. host. POST /v1/authentication on https://api.charitips.com with the live pair answers 200 with an accessToken.Callscreate-token

• One token is reused for an hour.

  Create a token, keep it in memory or a shared cache, and create the next one when a call answers 401. The token endpoint is meant to be called once an hour, not before each call. Authentication
  Code review

  The code caches the token and calls POST /v1/authentication once an hour, or once after a 401, never before each call.

Campaigns

• The live charities selection and campaigns exist, and are active.

  Activation needs a selection with at least one charity. Store the live ids in your configuration, apart from the sandbox ones.
  Agent check

  GET /v1/charities-selections?includeCharities=true returns each selection id of the live configuration with at least one charity; GET /v1/campaigns returns each campaign id of the live configuration with status: ACTIVE.Callslist-charities-selectionslist-campaigns

• Fixed budgets are paid.

  A campaign with a fixed budget is usually invoiced when you activate it, and opens once the invoice is paid. A budget above what your card or SEPA direct debit can be charged at once is refused, on live only.
  Agent check

  A campaign with amountType: FIXED_AMOUNT reads status: ACTIVE once its invoice is paid; one still PENDING after activation is waiting for payment.Callsget-campaign

• Receipts are set the way you want.

  Each campaign issues receipts once a year (the default) or when it closes (fiscalReceiptType). When your users pay, send their name and postal address, or withFiscalReceipt: false when they decline a receipt, and offer charities that issue receipts. Billing and fiscal receipts
  Agent check

  fiscalReceiptType on each live campaign is the one you want. When your users pay, GET /v1/charities-selections?includeCharities=true shows fiscalReceiptsSupport: ENABLED on each charity they can pick.Callsget-campaignlist-charities-selections

Calls

• Every create sends a uniqueExternalId.

  Donations, votes, donors and recurring donations. A retried call then answers 409 instead of creating a duplicate.
  Code review

  Every POST /v1/donations, /v1/votes, /v1/donors and /v1/recurring-donations body carries uniqueExternalId, set to your own id for the event, and a 409 is handled as a success.

• Donations are created from your server.

  After the event that triggers them (a paid order, a validated referral), not from the browser.
  Code review

  No call to api.charitips.com and no credential in browser or mobile code; the create call runs after the event is confirmed.

• Errors are handled by status.

  402: a plan feature or a payment method is missing, alert your team. 403: the state of the resource refuses the call, do not retry. 409: the resource already exists or is no longer pending, read it. 429: wait for Retry-After. Errors Troubleshooting
  Code review

  The error handling branches on the HTTP status as described; only a 401 with a new token, a 429 after Retry-After and a 500 are retried, once.

Webhooks

• Webhooks are created on live, with the events you listen to.

  A sandbox webhook only receives sandbox events.
  Agent check

  GET /v1/webhooks on live returns a webhook whose target is your live endpoint, with every event your code handles in events.Callslist-webhooks

• The signature is checked with the live signingKey.

  It is shown once, when the webhook is created: store it then. Check it on the raw body, before parsing it. Webhooks configuration
  Code review

  The handler verifies X-Charitips-Signature on the raw body with the live signing key, as in Webhooks configuration, and refuses a bad signature with a status Charitips does not retry.

• Handlers are idempotent.

  Events are delivered at least once, and internal updates send events too.
  Code review

  The handler keys its effects on the resource id and its status, so a second delivery changes nothing.

• Your endpoint answers 2xx once it has stored the event.

  Charitips retries only after 429, 500, 502, 503 or 504; any other error status is not retried. Webhooks configuration
  Code review

  The handler stores the event, then answers 2xx; it answers 5xx only when the event could not be stored.

Business customers, if you have them

• Child accounts are created on live.

  Each with its legal registration number and postal address in its fiscal info, which fiscal receipts need.
  Agent check

  GET /v1/accounts/{accountId}/child-accounts returns each customer with status: VALIDATED; GET /v1/accounts/{childAccountId}?includeFiscalInfo=true on each one returns a fiscalInfo with legalRegistrationNumber, street, zip, city and country.Callslist-child-accountsget-account

• The billing mode is chosen.

  For business customers, you can be invoiced for all of them, or each one is invoiced directly by Charitips. Account hierarchy Bill your business customers
  Manual

  A decision for your team, taken when each child account is created. billingInfo.billedTo on a child account reads ACCOUNT when the customer is invoiced directly, PARENT_ACCOUNT when you are.Callslist-child-accounts

Let your agent check this

1Read https://www.charitips.com/docs/get-started/go-live.md and check my integration against its go-live checklist. Use the live credentials from the environment variables CHARITIPS_CLIENT_ID and CHARITIPS_CLIENT_SECRET against https://api.charitips.com: create one token with POST /v1/authentication, then run only the GET calls the agent checks name. Never create, update or delete anything else, and never print a credential or a token. For the code reviews, read my code. For the manual items, tell me what to confirm and where. Report item by item, with its id: passed, failed with the reason, or manual.

Sandbox or live

What changes between the two environments:

• API host: api.sandbox.charitips.com on the sandbox, api.charitips.com on live.
• Widgets: embed.sandbox.charitips.com on the sandbox, embed.charitips.com on live.
• Credentials: start with test_ on the sandbox, with live_ on live. Each pair only works on its own environment.
• Payments: a test card and a test SEPA account on the sandbox, given on the Sandbox page; real money on live.
• Payment method checks: donations skip them on the sandbox; on live, the paying account needs a payment method.
• Card and SEPA amount limits: never applied on the sandbox; a fixed budget above the limit is refused on live.
• Subscription: needed on both to activate a campaign.
• Data: separate. An id from the sandbox does not exist on live, and answers 404 or 400.