The Stripe demo records give you a stable, realistic example Integration for learning Payloads and capturing documentation screenshots.

The demo is designed to show multiple Payload types, Credentials, Transformations, Data Queries, request and response bodies, Data Targets, and Jobs without using live customer data. It gives the documentation a consistent story: a Salesforce org using Payloads to model checkout, payment events, fulfilment, status lookups, and supporting authentication.

Use the demo when you want screenshots and examples to stay consistent across releases.

The Stripe demo groups the configuration records used across the documentation examples.

The Stripe Commerce Operations demo models common payment and fulfilment workflows.

It includes examples such as:

The Integration description includes a link to the Stripe API documentation so the demo can be compared with a real external API shape. The records are still demo-safe, but the structure is close enough to real REST API work to make the articles easier to follow.

Seeded records keep screenshots and examples consistent.

Use them when writing or updating help centre articles so names, values, Job statuses, and related records are predictable.

Do not use ad hoc records such as New integration or temporary test Payloads in screenshots. Clean those up before capturing images. Screenshots are easier for users to follow when every article uses the same Integration names and demo values.

Use the repo scripts to seed the demo org.

Run the Stripe seed scripts against the documentation demo org when the sample data needs to be refreshed.

The demo scripts create or update records rather than relying on manual setup. That makes the article screenshots repeatable between releases and reduces the chance that one article quietly drifts away from the rest of the documentation.

The Stripe demo uses demo-safe credential values.

Do not use real Stripe keys, live customer credentials, or production endpoint secrets in screenshots.

If you need to show a Credential, use the seeded test API key or demo bearer token Credential. The point is to show the configuration pattern without exposing anything that could be mistaken for a live secret.

The seeded Jobs cover multiple statuses and runtime outputs.

Use them when writing runtime articles because they show realistic request bodies, response bodies, Data Query output, Data Target output, response statuses, and performance metrics.

That makes runtime documentation much easier to write well. Instead of inventing abstract examples, you can point to a completed or failed Stripe demo Job and explain the exact fields a user should inspect.

For Job details, see Understand Job records.

Before taking screenshots:

Before using the demo in an article, check that:

If the demo records drift, reseed them rather than fixing screenshots manually.