Card Payments Integration Guide with Flagright API
Let’s take an example of a card payment to see how the Flagright API can be seamlessly used as the compliance and anti-financial crime infrastructure for real-time transaction monitoring. This guide covers various card-related use cases, structured around three common real-world flows:
- User to External Party (Outgoing): Funds leaving a user’s card to an external entity (e.g., merchant or third-party account).
- External Party to User (Incoming): Funds entering a user’s account from an external card or source.
- User to User (Internal): Transfers between users within the platform using cards.
The integration connects your user onboarding (KYC/KYB) system and core transaction processing system to Flagright’s endpoints, ensuring secure data exchange via REST API and webhooks.
Prerequisites
Before using the Flagright API for real-time transaction monitoring of card payments, complete the following setup steps to ensure a smooth integration. These steps apply to both sandbox and production environments:
- Security and authentication
- Get the API key in the Flagright console
- Include the API key in the x-api-key header of all requests, as shown in the example below.
- All API requests must use HTTPS; plain HTTP calls will fail. Authenticate requests with an API key retrieved from the Flagright console’s developer settings page. Store the key securely in a secrets manager or digital vault, as it can only be retrieved twice.
- Set up /consumer/users, /business/users, /transactions, and /events endpoints in your systems. Refer to https://docs.flagright.com/api-reference/introduction/getting-started for setup.
- Set up Rules and Risk factor configurations:
- Configure your Risk factors in the Flagright console to define behaviors for transaction monitoring (e.g., high-risk country checks, amount thresholds, or card-specific fraud detection).
- Rules like “High risk country” or “Transaction amount >= 10000 USD” (as shown in the example response) must be set up to trigger appropriate actions (ALLOW, FLAG, SUSPEND, BLOCK).
- Contact your Customer Success Manager or refer to the Rules and Risk factors configuration guide in the Knowledge base for customization.
- Prepare card payment data:
- Collect and format card payment details as required by the
originPaymentDetails
ordestinationPaymentDetails
object, such ascardFingerprint
,cardBrand
,cardLast4Digits
etc. - Ensure compliance with payment standards (e.g., ISO 8583 for posDetails.entryMode) and include optional fields like 3dsDone or cardAuthenticated for enhanced fraud detection.
- Collect and format card payment details as required by the
By completing these steps, you’ll be ready to integrate the Flagright API for real-time verification of card transactions, as demonstrated in the following sections.
Setting Up Entities
Business Onboarding
When a business entity joins your platform to send or receive card payments, create them using the Create Business User endpoint (POST /business/users). This sends user data for KYB and risk assessment.
Consumer User Onboarding
For individual consumer users making or receiving card payments, create users via the Create Consumer User endpoint (POST /consumer/users). This handles KYC data.
Card transaction scenarios
Real-time transaction monitoring allows you to verify and make a risk assessment on card transactions before they are processed. This enables you to identify high-risk transactions, potential fraud, and regulatory compliance issues before funds are moved.
For any transaction type (deposit, withdrawal, transfer etc.), you would make an API call to the POST /transactions
endpoint to verify the transaction before processing.
Below are sample payloads for the three flow types, with the use cases each covers.
1. User to External Party (Outgoing)
This payload represents funds leaving a user’s card to an external entity (e.g., a merchant). It uses originPaymentDetails.method: “CARD” for the sender’s card and includes merchantDetails for the recipient.
Use Cases Covered:
- Payments (e.g., card purchases at external merchants, online or POS).
- Withdrawals (e.g., ATM cash-outs to external networks; adapt by adding ATM details in tags and setting type: “WITHDRAWAL”).
- Outgoing Transfers (e.g., sending from user card to external account).
2. External Party to User (Incoming)
This payload represents funds entering a user’s account from an external card. It uses originPaymentDetails.method
as CARD
for the external funding card and destinationPaymentDetails for the user’s receiving account.
Use Cases Covered:
- Deposits (e.g., top-ups from external cards to user wallet/account).
- Refunds (e.g., credits from external merchants to user; adapt with type: “REFUND”).
- Incoming Transfers (e.g., receiving from external accounts to user card).
Response Structure
The API response contains comprehensive risk assessment information, including:
- Transaction status (ALLOW, FLAG, SUSPEND, BLOCK)
- Risk scores and risk levels
- Executed rules with detailed information
- Specific rules that were triggered for the transaction
The response is consistent across all flow types. Here’s an example for the user to external party payload:
Understanding the Response
Risk Scores
The riskScoreDetails
section provides comprehensive risk assessment information:
trsScore
: Transaction Risk Score on a scale of 0-100 (40 in this example, indicating MEDIUM risk)trsRiskLevel
: Risk level categorization (VERY_LOW, LOW, MEDIUM, HIGH, VERY_HIGH)originUserCraRiskLevel/Score
: Risk assessment for the sending userdestinationUserCraRiskLevel/Score
: Risk assessment for the receiving user
Rule Execution
The executedRules
array lists all rules that were evaluated for the transaction:
Hit Rules
The hitRules
array contains only the rules that were triggered for the transaction. In our example, the “High risk country” rule was triggered because the origin country (Bulgaria) is marked as high-risk in the system’s configuration.
Updating Entities and Transactions
Use the Create Transaction Event endpoint (POST /events/transactions) to update transaction states (e.g., “SUCCESSFUL”, “REJECTED”) post-verification. Transaction events encapsulate changes in status (e.g., from “CREATED” by default to other states).
For user updates (e.g., status changes), use user events endpoints. User events for consumers capture significant changes like account creation, modification, or verification status updates. Business events focus on activities like account setups, transaction monitoring for compliance, or changes in business operation details.
These events are crucial for tracking user engagement and compliance, and can trigger notifications or automated workflows.
Webhook Integration
Webhooks notify your system of events from Flagright (e.g., user/transaction state changes, new alerts, case closures). Setup steps:
- Identify events and payloads.
- Create an HTTPS endpoint on your server.
- Handle requests by parsing events and returning 2xx status.
- Deploy the endpoint publicly.
- Register the URL in the Flagright console and select events.
Verify webhook signatures using HMAC-SHA256 with your signing secret (from console) and the request body. This ensures authenticity.
Data and Implementation Flow
Data flows via API from your systems to Flagright (e.g., user/transaction data) for processing, with responses guiding actions. Webhooks flow from Flagright to your systems for operational updates triggered by console actions, such as rule hits, status changes, or alert creations.
- Pre-Transaction:
- Call the Flagright Transactions API (POST /transactions) before executing the card payment to send transaction details and receive real-time risk assessment.
- Review the response: The status field indicates the action (hierarchy: BLOCK > SUSPEND > FLAG > ALLOW). For SUSPEND or BLOCK, hold or decline the payment; for ALLOW or FLAG, proceed while noting any flags for review.
- Process approved transactions (ALLOW/FLAG) in your core system.
- Post-Transaction:
- For approved transactions, update the status (e.g., “SUCCESSFUL” or “REJECTED”) via the Transaction Events API (POST /events/transactions) to complete lifecycle tracking.
- Report any failed, rejected, or post-approval changes back to Flagright through events for ongoing monitoring and compliance.
This flow ensures seamless integration, maintaining regulatory compliance while enabling efficient card payments. Use webhooks (as detailed in the Webhook Integration section) for real-time notifications on post-transaction events, such as SUSPEND resolutions or alert closures, to close the operational loop.
Error Handling
API response codes include:
- 200: Successful
- 400: Bad request (invalid payload)
- 401: Unauthorized (invalid API key)
- 403: Forbidden (wrong authentication)
- 429: Too many requests (rate limit reached)
- 500: Server error (contact Flagright support)
If the API call fails (e.g., 400 Bad Request for invalid payload or 401 Unauthorized for invalid API key), check the response for error details. Default to SUSPEND or BLOCK for safety in production.