This is the final step in our blog series for adding Amazon Web Service (AWS) powered real-time fraud detection to Sugar Sell. In our first blog, we proposed an e-commerce application that allows users to 1) signup and 2) transact payments at checkout. In both cases, Sugar checks for Fraud in its database or using AWS powered Fraud Detection.
For our e-commerce, we have elected expressCart, an easy to use open source project. For Sugar, we will utilize as much as the platform has to offer, after all, we want to “Let the platform do the work”.
Fraud Detection Sequence Diagram
The following diagram shows the interaction between users and systems/components as well as the logic involved in the fraud detection process.
Both, Signup and Checkout Transaction, have similar flow, always triggered by an end-user consumer who wants to either signup or simply checkout an e-commerce cart.
- E-commerce user tries to sign-up or checkout
- E-commerce system validates form data (not null, valid email, credit card)
- E-commerce system triggers Sugar API for validation
- Sugar checks internally if a previous fraud detection prediction is still valid or needs a new Prediction from AWS Fraud Detection API
- Sugar triggers AWS Fraud Detection Realtime prediction and saves the result
- SugarBPM kicks in and evaluates the outcome from AWS Realtime Prediction
- If outcome is fraud, then SugarBPM notifies the team assigned to deal with the suspected fraud
- Sugar User opens the fraud form, evaluates the outcome and data and decides to “Approve” or “Reject” that sign-up or transaction.
- Sugar Webhook gets triggered by this approval update and notifies E-commerce system
- E-commerce stores decision from Sugar and uses in the next login and/or checkout.
E-commerce (Store Front)
expressCart is a fully functional shopping cart created in Node.js (Express, MongoDB) with built-in connections with popular payment providers. We are focusing on the store front functionality as part of our integration with Sugar. A user can browse, search, and add items to your shopping cart and checkout.
E-commerce (Sign-in / Sign-up)
At checkout time, expressCart provides a “Customer Details” section where you can login as returning customer, checkout without an account, or create an account while checking out. For our exercise, we’re removing the “checkout without an account” option so the user must log-in.
At this point, you can either login or create an account. If creating, expressCart requests Sugar to score this signup attempt. Non-successful attempts, scored either as “Fraud” or “Requires Review”, are presented with the following message.
We are storing the result in expressCart database, which will be used to prevent the user from proceeding until there is an approval in Sugar.
E-commerce (Payment)
After sign-in or signup, user is redirected to the payment details screen, where data is captured by our fake payment gateway*. When user submits payment, expressCart requests Sugar to score this transaction attempt.
If that transaction is scored as “Fraud” or “Requires Review”, expressCart presents the following message as well as set the order as “Pending”. If the card has been cleared/approved by Sugar User as part of the BPM process, the store front user can retrieve the order and retry the payment again.
* We have created a fake payment gateway that captures basic credit card data as part of our example. To be plain, it is unrealistic to do this in production due to PCI compliance requirements. Usually payment gateways such as Stripe, Paypal amongst other do provide APIs to be integrated with in a PCI compliant way. They also provide their own “Fraud Detection” services, which can overlap what we’re trying to accomplish.
SugarBPM Review Process
SugarBPM is an easy-to-use business process management (BPM) and workflow tool that adds advanced BPM functionality to Sugar and will be used to manage AWS Fraud Detection’s outcome and mark it as Approved or request a Review from our Sugar Users.
Both Sign-up and Transaction processes have a similar BPM workflow represented by:
- SugarBPM is triggered when a new Sign-up or Transaction record is created
- First condition checks whether the outcome is approved, if so, we mark the record as approved and ends there, no Sugar User interaction is required.
- If the outcome is different than Approved, a Sugar User manual intervention is required and a form "Approve/Reject” is available to their team.
- Sugar User analyses the data and either approves or rejects the record.
- A record might be flagged as “Fraud” but the end user can still override that by approving the transaction manually.
- After manual approval/rejection, SugarBPM marks the record as Approved/Blocked and finishes the process.
Sign-up and Checkout Transaction BPM processes should be routed to a team of individuals trained and skilled to deal with Fraudulent transactions. A common practice is to have two different teams setup in Sugar, one for credit card and one for sign-ups. You can set the team and assignment method using SugarBPM so they will be routed accordingly.
Sugar Sell’s E-commerce Activity Dashboard
A new dashboard has been created for our Fraud Specialists to easily follow our E-commerce activity. This dashboard contains 3 main dashlets:
- Processes (display an individual’s queue of reviewable processes)
- Latest Signup Attempts (display all sign-up attempts)
- Latest Payment Transactions (display all payment transaction attempts)
Fraud Specialists (Sugar Users) can edit these pre-built dashlets to present information more relevant to them. They can configure the display fields, the number of records to display, auto-refresh frequency, and any many other options.
E-commerce Activity Processes
This out-of-the-box dashlet provides a list of processes that were assigned to the Fraud Specialist’s queue. For example, if the Fraud Specialist is assigned to both Signup and Transaction teams, then active processes would be displayed as follows:
Remember, SugarBPM routes “actions” not the process, so you may have multiple different actions as part of in a single process.
E-commerce Activity Processes Approve/Reject
When user opens process record view screen, they are presented with the Record View Layout for that module, in this case Signup or Transaction with option to Approve or Reject.
When the Fraud Specialist user makes an approve or reject determination then the BPM workflow continues and updates our signup/transaction status before terminating.
E-commerce Activity Latest Attempts
Latest attempts lists are out-of-the-box list view dashlets configured for each module and columns organized in a way that Fraud Specialists can look at it and make a decision right away.
expressCart Source Code
As part of this blog series, we have customized expressCart to fit our sign-up and shopping cart transactions use case. Such customizations are not relevant to the rest of expressCart community so we’ve forked it and applied the customizations there.
Our “blog post contribution” and all resources used in our example are easily comparable in this PR. It is out of the scope of our series to add detailed validations and/or UI beautification other than what expressCart already had in place, feel free to contribute to our fork here.
It’s worth mentioning that we’re using Axios interceptors to deal with authenticated requests from expressCart to Sugar. It’s a technique that intercepts “unauthorized” errors in requests to Sugar and when found, re-authenticates (gets new token) and re-tries the request automatically. Our interceptors are here for your reference.
Sugar Source Code
You can find all the source code for our series in our GitHub project. It has been organized in 2 distinct folders.
- fraud-detection-app contains our AWS NodeJS App responsible to create all supporting resources for this project in AWS *
- sugar-package contains our Sugar resources such as MLP code and Postman collection to insert necessary DB/Config/BPM onto Sugar instance.
Packaging Sugar Module Loadable Package.
Our Module Loadable Package (MLP) can be easily packaged by using Enrico Simonetti’s sugar-module-packager, a very convenient method of packing Sugar MLPs by using Docker. No installation required, , just run this command and it will generate a composer and necessary files for packing:
mkdir my-module
cd my-module
docker run -it -v ${PWD}:/usr/src/packager -w /usr/src/packager esimonetti/sugarmodulepackager new
Once that’s done, you can conveniently use the following to generate your MLP zip file, (plus you can see your “packaging expanded files” under /pkg”, as you can see, very convenient:
./vendor/bin/package <version number> ie: ./vendor/bin/package 1.6
Your MLP package is now ready to be installed into to a Sugar instance. It can be easily added to your instance manually using Admin’s Module Loader or through Sugar’s Rest API. An example for installing an MLP via the REST API can be found in our Professor-M postman collection.
Make sure you install the MLP before you run the data import using the Postman Collection below.
Postman Collection
Postman is an API development environment. You will find under sugar-package a “data” folder which contains a postman collection as well as our BPM exported files. This collection imports our “E-commerce Activity” dashboard, sample data for signups and transaction as well as import our BPM processes so you can have this project ready to go on your instance and improve it as necessary.
A pretty detailed explanation on how to execute Postman manually or through Docker can be found in our Professor-M project. For this, we’re using docker for its simplicity. Make sure your “Sugar_Fraud_Detection.postman_environment.json” is properly set before executing it.
docker run -v pathToTheDataDirectory:/etc/newman -t postman/newman_ubuntu1404 run "Sugar_Fraud_Detection.postman_collection.json" --environment="Sugar_Fraud_Detection.postman_environment.json"
WebLogic Hook
Our final setup step is to create a WebLogic Hook on Module Signup pointing to your e-commerce URL. This hook will trigger on every save and will communicate your decision back to e-commerce application. The URL template is: http://<your expressCart URL>/customer/signup_webhook
Conclusion
Fraud Detection can be a cumbersome process to companies using an E-commerce sales channel and if not dealt properly can yield large financial consequences due to fraud. This series helps you avoid and navigate this potential problem by guiding you every step of the way from gathering your data, training prediction models, and integrating with Sugar Sell to oversee all the E-commerce activity to help prevent fraud. How about that?
Sugar Sell guides users through the process to approve or reject sign-ups or transactions and communicates these decisions back to the e-commerce application. All of that with minimum amount of code.
I personally learned a lot researching, coding, and writing this series. I want you to have fun learning from it too.
What do you think I should write about next?
References
Adding AWS fraud detection to SugarCRM
Adding AWS powered fraud detection to Sugar Sell - Part 2
Adding AWS powered fraud detection to Sugar Sell - Part 3
https://aws.amazon.com/fraud-detector/