Certification reference

Base payloads, test cards, and status tables for the Certification guide. The test cases cite these by appendix letter.

Appendix A. Base payloads

Reference: /evaluate, Payload examples, /capture, /refund.

Each case changes only the fields it names. Replace every placeholder with your sandbox values.

A.1 Base CIT payload

POST /v1/evaluate
Authorization: Bearer {accessToken}
Content-Type: application/json

{
  "mid": "{sandbox MID}",
  "isDeclined": true,
  "orderId": "{merchant order ID, unique per case}",
  "siteId": "{sandbox Site ID}",
  "idempotencyKey": "{new GUID per case}",
  "isMIT": false,
  "transactionType": "PURCHASE",
  "customerIp": "203.0.113.45",
  "attemptCount": 2,
  "transaction": {
    "id": "{merchant transaction ID}",
    "amount": 9900,
    "currency": "USD",
    "timestampUtc": "{now, ISO 8601 UTC}",
    "timezoneUtcOffset": -6,
    "responseCode": "05",
    "responseCodeSource": "processor",
    "responseDescription": "Do Not Honor",
    "processorName": "{original processor}",
    "avsResultCode": "Y",
    "cvvResultCode": "M",
    "cardNotPresent": true
  },
  "payer": {
    "email": "[email protected]",
    "phone": "5125550123"
  },
  "billingInformation": {
    "firstName": "Jane",
    "lastName": "Smith",
    "addressLine1": "123 Main St",
    "city": "Austin",
    "state": "TX",
    "zipcode": "78701",
    "country": "United States",
    "countryCode": "US"
  },
  "paymentMethod": {
    "cardNumber": "{token from TOKENIZE-01, or the PAN on the DIRECT-CARD path}",
    "token": true,
    "cardBinNumber": "400000",
    "cardLast4Digits": "3184",
    "expirationMonth": 12,
    "expirationYear": 2028,
    "holderName": "Jane Smith",
    "cardType": "credit",
    "cardBrand": "Visa",
    "cardCountry": "US"
  },
  "merchant": {
    "id": "{merchant identifier}",
    "mcc": 5999,
    "country": "US"
  }
}

On the DIRECT-CARD path, set token to false and send the PAN in cardNumber. Add verificationValue when the case calls for a CVV.

A.2 Base MIT payload

Same as A.1 with these changes. Remove customerIp and verificationValue.

{
  "isMIT": true,
  "isRecurring": true,
  "transactionType": "PURCHASE",
  "attemptCount": 3,
  "transaction": {
    "responseCode": "51",
    "cvvResultCode": "P"
  },
  "subscription": {
    "subscriptionId": "{merchant subscription ID}",
    "price": 9900,
    "currency": "USD",
    "interval": "monthly",
    "schemeTransactionId": "{network transaction ID from the original CIT}"
  }
}

expiryDateUtc is optional. Add it only where a case names it.

A.3 Capture request

POST /v1/capture
Authorization: Bearer {accessToken}
Content-Type: application/json

{
  "orderId": "{FlexFactor orderId}",
  "amount": 9900,
  "currency": "USD",
  "idempotencyKey": "{new GUID per capture}"
}

A.4 Refund request

POST /v1/orders/{orderId}/refund
Authorization: Bearer {accessToken}
Content-Type: application/json

{
  "amountToRefund": 99.00,
  "refundMessage": "Certification test",
  "idempotencyKey": "{new GUID; required by this guide on every partial refund}"
}

Appendix B. Test cards used in this guide

The full sandbox card list is on the Sandbox Test Cards page. Use [email protected] as the email and a valid US or CA phone number unless a case states otherwise.

Card	Outcome	CVV	Other data
`4000002760003184`	Approved rescue	Any, or omitted	Any name and address
`4444555566660030`	Approved rescue	Any, or omitted	Any name and address
`4111111111111111`	Approved rescue	`999`	Any name other than `Cure Tester`
`4111111111111111`	CHALLENGE	`999`	Name `Cure Tester`; phone `+99.0007` (ask for CVV), `+99.0003` (different card), `+99.0002` (3DS)
`4012888888881881`	Declined rescue	Any	Any name and address

Appendix C. Status reference

C.1 Evaluate response status

Reference: /evaluate response status.

`status`	Flows	Action
`APPROVED`	CIT-PURCHASE, SYNC-MIT retry	Mark the order paid
`DECLINED`	CIT-PURCHASE, CIT-AUTHORIZE, SYNC-MIT	Return the original decline
`CHALLENGE`	CIT-PURCHASE	Treat as a decline
`CAPTUREREQUIRED`	CIT-AUTHORIZE	Call `/capture` within the capture window
`SUBMITTED`	MIT-ASYNC-PURCHASE, MIT-ASYNC-AUTHORIZE	Hold the order pending; wait for the webhook

DECLINED is also the fallback value when result is Failed. In that case success is false, and the response is not a FlexFactor decision; return the original decline.

C.2 Order status

Returned by GET /v1/orders/{id}. Reference: Order status, GET /orders/{id}.

`status`	`statusName`	Meaning	Action
0	`Draft`	MIT order received	Pending
1	`Onhold`	Temporarily on hold	Pending; no webhook
2	`Cancelled`	Cancelled, declined asynchronously, or expired	Not rescued; check for `order.expired`
3	`Problem`	Processing problem	Not rescued; contact support with the `orderId`
4	`Processing`	Rescue in progress	Pending
5	`Capturerequired`	Authorized, not captured	Call `/capture`
6	`Returned`	Defined in the enum; not assigned by a refund	Not expected; contact support with the `orderId` if observed
7	`Completed`	Captured; stays `Completed` after a full or partial refund	Paid; read `refundsAmount` for refunds

C.3 Webhook events

Reference: Webhooks.

Event	Priority	Fires when
`order.completed`	Recommended	An order reaches `Completed` on any flow, including synchronous CIT approvals and successful captures; delivered after the API response
`order.cancelled`	Recommended	An order is cancelled by you, or an MIT rescue is declined; sent only when the order status changed
`order.expired`	Recommended	An MIT rescue window closes without an approval, or an authorization is not captured within the capture window
`order.capturerequired`	Critical for MIT-ASYNC-AUTHORIZE and SYNC-MIT	An authorization is approved and awaits capture
`order.refunded`	Critical	A refund you initiated is processed
`payment.chargeback.received`	Critical	The issuer raises a chargeback
`payment.chargeback.reversed`	Recommended	A chargeback is reversed in the merchant favor
`payment.early_warning.received`	Recommended	A TC40 or SAFE alert arrives before a chargeback
`challenge.presented`	Critical for challenge flows	`/evaluate` returns `CHALLENGE`

C.4 Response envelope by endpoint

Reference: Workflows §3.5.

Endpoint	`status` values	`result`	`success`
`POST /v1/evaluate`	`APPROVED`, `DECLINED`, `CHALLENGE`, `CAPTUREREQUIRED`, `SUBMITTED`	`Success` or `Failed`	`false` only when `result` is `Failed`
`POST /v1/capture`	`SUCCESS`, `FAILED`	Always `null`	Stays `true` when `status` is `FAILED`
`POST /v1/orders/{id}/refund`	`SUCCESS`, `FAILED`	Always `null`	`false` when `status` is `FAILED`
`POST /v1/orders/{id}/cancel`, `POST /v1/orders/{external-order-id}/external-cancel`	No `status` field	Not present	`true` on HTTP 200, also when nothing changed

statusCode is never populated on any of these endpoints. errors items are serialized positionally: item1 message, item2 key, item3 code, item4 friendly flag.