Working with checkpoints

Checkpoint strategy

We recommend adding Composer checkpoints at the key points in your application's user journey — wherever you want to make a decision, run a transaction, or both. By default, checkpoints allow all requests to proceed. As you learn more about the fraud you're seeing, or as you build out payment logic, you can add that logic to the checkpoint.

📘
Checkpoints are the primary way you use Composer. They contain the logic that determines whether a request should be allowed to proceed, and can run an actual payment transaction as part of that logic. This allows you to protect your application and process payments without having to touch your code.

Create a checkpoint

Go to Checkpoint Studio and click Create New Checkpoint. Give it a name that describes the action it handles — e.g. CREATE_ACCOUNT, LOGIN, CREATE_LISTING, MAKE_PAYMENT. You can also add a description to help you remember what the checkpoint is for. While there is no limit to the number of checkpoints you can create, each one must have a unique name.

📘
Your code calls checkpoints by name. To prevent unintentionally breaking your code, you can't change the name of a checkpoint once it's created.

We recommend starting with an empty checkpoint. You can then immediately publish the checkpoint, and all requests will proceed by default. As you learn more about the fraud you're facing or build out your payment logic, checkpoints can reference third-party services from the Service Catalog, run payment transaction steps, or call your own internal systems via API — add that logic incrementally.