Skip to content

Home

Jump to bottom
arush edited this page Sep 16, 2016 · 42 revisions

Table of Contents

The Try.com Integration consists of a Drop-In UI and an optional server-side integration. This is how can support super quick (2 lines of code) integrations all the way up to full sophisticated integrations. If we have a plugin for your platform, you get a sophisticated integration for free!

  1. Create Merchant Account
  2. Install
  3. Drop-In UI
    1. Javascript SDK
      1. Initialize SDK
      2. (Optional) Checkout with Try.com (Express Checkout button)
      3. (Optional) Try Button
    2. iOS (Coming Soon)
  4. Create Order
    1. Manual (no integration required, but not recommended)
    2. Shopify
    3. Other Popular Platforms
    4. Custom Installation (any platform)
      1. Create Order Using Try.com Checkout Data
      2. Receive Risk Decision
      3. Order Fulfillment
      4. (Optional) Cancel Order
  5. (Optional) Returns RMA Integration
    1. Obtain Return Tracking Number
      1. Return Label in box
      2. Return Label not in box
    2. Return Parcel Created
  6. (Optional) Reconcile Returns
  7. Configure Emails
  8. Analytics Guide
    1. Frontend Analytics Docs
    2. Server-side Analytics (Coming Soon)

Analytics Guide

All aspects of the Try.com experience are exposed, so you can feed them to whichever BI/analytics tools you already use. This allows you the deepest level of integration, providing you ultimate flexibility as if you owned the Try.com codebase in house.

Frontend vs Server-side Strategy

It is important to understand that some events are triggered on the customer's browser/app (frontend), and some are triggered on the server-side. These events are always mutually exclusive, we never send the same event from both the frontend and server-side.

Frontend vs Server-side Source Example

For example, the frontend is responsible for capturing events like register.via_email.viewed to signify that the email registration page was presented to the user. However, user.registered is a server-side concept, so that is a server-side event.

Naming Strategy

We use dot notation to help analysts make sense of the huge amount of events we expose across all our apps, products and platforms.

There may be some exceptions, but normally, we aim to use the following naming strategy:

[feature].[entity.heirarchy].[optional_modifier].[action]

The important thing is that events always end in a verb in past tense. A feature is a major subcomponent of the Try.com ecosystem, for example, try_button, express_checkout, risk, merchant_portal, consumer_portal. Sometimes it doesn't make sense to include a feature, especially for server-side events.

In terms of English grammar, this usually means:

[noun].[noun].[optional adjective].[verb (past tense)]

Naming Example

// If you are using the Express Checkout product, when the user is presented with the Facebook Connect registration page, the following event gets fired from our Javascript SDK.

express_checkout.user.register.via_facebook.viewed

Server-side Analytics Events

These events can be consumed by merchants via webhook. You are able to register your server-side analytics callback endpoint via the Merchant Portal.

  • Full list of server-side events (coming soon)

If there is an event you would like us to expose, let us know at engineering@try.com and we can probably enable it pretty quickly.

Frontend Analytics Events

These events can be consumed by merchants via our frontend SDKs (Javascript, iOS, Android).

Clone this wiki locally