Repository navigation
Conversation
The verification result fields did not say what to send while a verification is pending. A merchant could send false for a link that the user has not clicked yet, and minFraud would see a failed check. Define the result as that of the most recent completed verification. A pending, abandoned, or expired verification is not complete and is not a failure. If no verification is complete, leave out the field. The phone method field described the most recent verification attempt, which can be pending. Make it describe the same completed verification as the result field, so that a merchant does not send a method from a pending attempt next to a result from an earlier one. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
"The most recent date and time a verification was attempted" could mean the time the merchant sent the link or code, or the time the user used it. For email, these times can be days apart. Define the time as the time the most recent completed verification succeeded or failed. A pending verification is neutral, so the time a link or code was sent is not a result time. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
You can score a stored event later with /event/time. The verification fields did not say whether to send the state at the time of the event or at the time of the request. If a merchant sends the current state, the model sees information from after the event. Say that the email and phone verification fields must reflect the state as of the time of the event. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The time fields did not say to leave out the field when no verification was attempted. An integration that always sends a value could send a placeholder such as 1970-01-01T00:00:00Z. The web service accepts it and records a verification that did not occur. Say to leave out the time if no verification was attempted or no verification is complete. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. Walkthrough
Merge Risk:
|
There was a problem hiding this comment.
🟢 Approval recommended
No unresolved review concerns are identified for the verification-field description updates.
No open issues 🎉
What changed in this PR
Clarifies minFraud’s email and phone verification input descriptions without changing schema structure or runtime behavior.
Changes:
- Specifies that verification fields describe the most recent completed verification as of the event time.
- Clarifies that timestamps record success or failure, not when a link or code was sent.
- Explains that pending, abandoned, and expired verifications are not failures, and fields should be omitted when no verification is complete.
| File | Description |
|---|---|
components/minfraud-request.yaml |
Updates the source descriptions for email and phone verification fields. |
bundled/minfraud.yaml |
Mirrors the clarified descriptions in the generated bundle. |
Review effort: Balanced
Makes the same changes to the minFraud verification field descriptions as maxmind/dev-site#1808. The text matches the developer site. Each commit covers one item:
verification_timeandphone_verification_timeare the time the verification succeeded or failed, not the time the link or code was sent.Only descriptions change. Each commit regenerates
bundled/minfraud.yaml.🤖 Generated with Claude Code
Summary by CodeRabbit