Integration
There are a number of scenarios wherein partners wish to integrate with the Figg API, and this guide will help your company get up and running as quickly as possible with the most common variants. This guide will offer direction based on what the partner would like to get from an integration. Please click on the appropriate link(s) below to get started:
Submit our users' cards for tracking (the partner is comfortable with their PCI compliance)
Have Figg obtain our users' cards for tracking (the partner wishes to avoid PCI compliance issues)
Obtain Figg network offers
Do I need all those API endpoints?
Please note that the API was originally written to service Figg, Inc, and as such contains a superset of functionality
required for any Figg integration. Most of the endpoints will not be necessary for any integration. You can ignore
anything under these headings:
BILLINGACCOUNTS, DEVICES, FUNDRAISERS, METROS
Furthermore, you'll be able to ignore most of the endpoints under the remaining headers, too, depending on the nature of your
integration, and the heading RESPONSE OBJECTS is for object-specific documentation, so you'll only go there in order
to learn a bit more about a specific object, auto-generated from reflection on the bean properties. The vast majority of our partners
only use a handful of methods.
Submit User's Cards for Tracking
When you, the partner, are PCI compliant, and merely wish to directly submit your user's cards for tracking, it's perhaps our simplest integration. We've created a document covering the steps for you to follow, please download it here.
Have Figg Obtain User's Cards for Tracking
In order to keep PCI compliance burdens at a minimum, Figg offers two options to help partners receive notifications about user card activity without having the handle the sensitive data. One option is web-based, and the other is more appropriate for use in a mobile app. There is nothing preventing a partner from using both options if they have such needs on both types of platforms. The web-based option is called "Hosted Fields", and the broad strokes are that the partner hosts a web page which includes javascript from Figg. When the page loads, it will call the Figg javascript, and Figg's javascript will create the appropriate fields for credit card registration. On submission, the information from those fields will go to Figg's servers, and Figg will return to the partner a token to use to manipulate that user / card. For a detailed description of Hosted Fields, please contact your account manager who may provide the documentation.
The option recommended for mobile apps is what we call the client user token grant. In this option, your app will have a place in its UI for your users to register a card. That app will typically request a token from your servers, which will serve to identify that user now and into the future. Your server will then request a "client_usertoken" access token from the Figg platform. Figg will return to the partner a token to use to manipulate that user / card, and that token can be given to the mobile app, so that the mobile app can then interact directly with the Figg API, and the user can then register his / her card directly with the Figg API without further involvement (or further PCI compliance burdens) from the partner's server. More details may be found here.