Proof-of-concept guide

A guide for organizations that prefer a more hands-on and trial

πŸ“˜

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, offers a more hands-on evaluation experience than a self-service trial. In a PoC, our customer success team will work closely with you to coordinate the integration and ensure that your success criteria are met.

A typical PoC lasts for 30 days, starting at the point of full implementation in your production environment. This allows you to test the product in a real-world setting and see how it performs. The self-serve trial, on the other hand, starts at the time of signup, which may not provide as much time for testing.

To make the most of your PoC, we will invite your team to a shared Slack channel and provide technical resources on our end to assist with coordination and ensure a smooth evaluation process. This will help speed up the PoC and make it as successful as possible.

Phase 1: Integration (2-4 weeks)

🚧

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.

  1. Integrate the Browser SDK
  2. Send page views from the Browser SDK
  3. Integrate the Server SDK
  4. Pass the request_token from the Browser SDK to the Server SDK
  5. Send successful registrations from the Server SDK. Make sure the user object is as complete as possible. You'll be re-using it for all the server-side calls
  6. Send successful logins from the Server SDK
  7. Send failed logins from the Server SDK
  8. Send profile updates from the Server SDK. The changeset details object can be added after the POC
  9. Send transactions from the Server SDK. The transaction details object can be added after the POC

Phase 2: Evaluation (2-4 weeks)

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.

Phase 3: After the PoC (4-8 weeks)

Assuming the PoC is successful, we will move into a longer-term partnership. The customer success team will work with you to identify actions in your application that can indicate suspicious or fraudulent behavior. These can be sent as custom events from the Browser or Mobile SDK, or the Server SDK, depending on what is most convenient for your developers.

Our team will also help you to configure the product to meet your specific needs and requirements. This will allow you to fully customize the product to fit your business and ensure that it performs effectively in your environment.

The following integration points are typically completed during this phase:

  1. Integrate the Mobile SDKs
  2. Send custom events from the Browser and Mobile SDKs
  3. Send custom events from the Server SDKs
  4. Send challenge events from the Server SDKs
  5. Send password reset events from the Server SDKs
  6. Enrich profile updates with changeset details
  7. Enrich transactions with transaction and payment method details
  8. Implement account takeover self-service workflows