Data-driven decisions
Score thin-file shoppers with alternative data and device signals, so checkout-speed approvals are also well-informed ones.
← Use cases / BNPL
Approve BNPL applicants instantly, without absorbing fraud losses.
Score every checkout in real time using alternative credit data, device risk signals, and blacklist checks — the signals come back inside the checkout request, not after a queue clears.
The shape · One circle split into four equal arcs — a purchase divided into instalments.
The problem
BNPL approval has to happen in the checkout flow — a shopper who waits more than a few seconds abandons the cart. That forces a bad tradeoff: approve fast using thin signals and eat the fraud losses, or add friction and lose the sale to a competitor's one-click checkout.
The solution
Smile scores the applicant in the same request window as checkout, combining alternative credit data with device and location signals that a thin credit file alone can't provide — so the checkout-speed decision is also a well-informed one.
What changes
How it works
From trigger to decision, in four steps.
STEP 1
Trigger the event
A shopper selects BNPL at checkout, and your frontend sends the checkout amount and shopper identifiers to your backend.
STEP 2
Call the API endpoint
Your backend sends a POST request to /v1/footprints with the applicant's email, mobile number, country code, and consent record.
STEP 3
Real-time processing & webhooks
Smile scores the applicant against alternative credit data, device signals, and blacklists, returning the result synchronously within the checkout request.
STEP 4
Deliver the output
Your checkout flow reads the fraud score and footprint signals, applies your own approval rules, and completes the order — no redirect, no queue.
The code
Request in, structured data out.
Request — cURL
curl -X POST "https://sandbox.smileapi.io/v1/footprints" \
-u "$SMILE_CLIENT_ID:$SMILE_CLIENT_SECRET" \
-H "Content-Type: application/json" \
-d '{
"consent": {
"type": "Terms And Conditions",
"version": "1.0",
"consentedWith": "I agree to the terms and conditions.",
"consentedAt": "2021-04-14T09:30:24Z",
"consentTemplateId": null
},
"templateId": "tpl-score-footprint",
"emailAddress": "gpalomero1234@smileapi.io",
"mobileNumber": "639559991234",
"countryCode": "PH",
"footprintItemsTimeout": 5
}'Response — 200 OK
{
"code": "OK",
"message": "Success!",
"requestId": "bc92fe7b-ca09-42e1-8c6c-ed2c373d9b01",
"data": {
"id": "fp-22bdb31d1cbd4009a00a18365d9f5ce9",
"createdAt": "2026-08-18T06:31:48Z",
"status": "COMPLETED",
"resultCode": "SUCCESS",
"resultMessage": null,
"requestMeta": { … },
"items": [
{ "name": "mobile.valid", "value": "true", "valueType": "BOOLEAN" },
{ "name": "mobile.carrier", "value": "Globe Telecom", "valueType": "STRING" },
{ "name": "mobile.registeredProfilesCount", "value": "5", "valueType": "NUMBER" },
{ "name": "email.registered", "value": "true", "valueType": "BOOLEAN" },
{ "name": "email.disposable", "value": "false", "valueType": "BOOLEAN" },
…
{ "name": "analysis.fraudScore", "value": "144", "valueType": "NUMBER" }
]
}
}Security & reliability
Built to be trusted in production.
Data privacy & compliance
Data is encrypted in transit and at rest, sensitive fields are tokenized rather than stored in the clear, and consent is captured at the point of collection — adapted to the data privacy regulations applicable in each market you operate.
Reliability
Idempotent requests, built-in retry support, and published rate limits mean a dropped connection or a retried request never produces a duplicate check. Each client can make up to 20 requests per second per IP address across all endpoints; anything above that returns HTTP 429.
Graceful failure
Every error returns a descriptive status code and a structured JSON body with a machine-readable code and a request ID — never a bare 500 — so a failed check is something your application can handle, not just log.
Under the hood
Relevant products
AI & data-driven decisions
How does Smile API power AI and data-driven decisions?
Smile API returns a structured risk profile inside the checkout window. BNPL decision engines and AI agents can set spending limits from verified data, not thin credit files.
Features for your models
Clean, labelled and consented attributes — identity, income, device and watchlist outcomes — ready to use as inputs for credit and fraud scoring models.
Context for AI agents
A checkout agent can read the fraud score and footprint signals, then approve, lower the limit or ask for more checks in real time.
Can an AI agent set BNPL limits with Smile API data?
- Yes. The agent receives the shopper's fraud score and footprint signals within the checkout request and applies your limit policy, so approvals stay fast and fraud-aware.
Is Smile API data structured for machine use?
- Yes. Results come back as consistent, typed JSON fields — verification statuses, scores and flags — so rules engines, machine learning models and large language model agents can read them without manual cleanup.
How is consent handled when AI uses Smile API data?
- Every request carries the consent record captured from the end user, and Smile returns only the signals that consent covers. Your models and agents work with permissioned data, never scraped or self-reported guesses.
{
"profile": "prf_8f21",
"identity": "verified",
"income": { "status": "verified", "source": "payroll" },
"device": "trusted",
"fraudScore": 0.07,
"watchlists": "cleared",
"suggestedAction": "approve_limit_low"
}