Interested in doing a proof-of-concept?
Please don't hesitate to reach out even if you're still unsure whether Castle is the best fit for your current needs. We're always happy to show you a demo of the product, and then determine whether a PoC is a better option for you than the self-serve trial.
A proof-of-concept, or PoC, is a more hands-on version of the self-service trial where our customer success team gets involved to help you coordinate the integration and ensure that your success criteria are met at the end of the evaluation.
A typical PoC will last for 30 days, starting at the point of when full PoC implementation is deployed into your production environment. The self-serve trial, on the other hand, starts the clock at the time of signup.
To speed up coordination during the PoC, we will invite your team to a shared Slack channel and and also invite technical resources on our end.
This guide is a curated version of A complete integration. Please read that guide first to understand all the details on how Castle works before following the instructions below.
In order for us to dedicate time to help you through a PoC, we require a minimal set of integration steps so that we can ensure that we have enough data to go off of at the end of the evaluation.
We normally recommend doing the POC on in your web environment since then we won't need to go through mobile app store approvals simply to test things out. However, if you're a mobile-only business, we will do the Mobile SDK(s) instead of the Browser SDK.
- Integrate the Browser SDK
- Send page views from the Browser SDK
- Integrate the Server SDK
- Pass the
request_tokenfrom the Browser SDK to the Server SDK
- Send successful registrations from the Server SDK. Make sure the
userobject is as complete as possible. You'll be re-using it for all the server-side calls
- Send successful logins from the Server SDK
- Send failed logins from the Server SDK
- Send profile updates from the Server SDK. The
changesetdetails object can be added after the POC
- Send transactions from the Server SDK. The
transactiondetails object can be added after the POC
Once the integration is completed, we will let the user activity flow in over the course of a week. This will allow our risk models to build up a baseline of what is normal user behavior on your platform. For example, our models automatically learn from where your users normally log in, how many devices they have on average, and how often they transact or update their profile settings.
Based on the initial data set, we will gather your requirements on what types of behaviors you'd like to be alerted about or even have blocked in real-time, and then use that knowledge to configure policies to trigger based on your needs.
This is where the PoC was proven to be successful, and we're ready to move into a longer-term partnership.
The customer success team will work with you to identify what actions in your application that can be indicators of suspicious behavior and outright fraud. These will sent as custom events from either the Browser or Mobile SDK, or the Server SDK, depending on what is most convenient for your developers.
The following integration points are typically completed during this phase:
- Integrate the Mobile SDKs
- Send custom events from the Browser and Mobile SDKs
- Send custom events from the Server SDKs
- Send challenge events from the Server SDKs
- Send password reset events from the Server SDKs
- Enrich profile updates with
- Enrich transactions with transaction and payment method details
- Implement account takeover self-service workflows
Updated about 2 months ago