Certification Scenarios
Required test scenarios you must complete before Cresora issues live API keys.
Complete all required scenarios in the sandbox before submitting for certification. Each scenario tests a critical part of your integration.
All scenarios marked Required must be completed and evidenced before Cresora issues production keys.
Card payment scenarios
Card capture happens through a hosted-page session (cards are never POSTed to the API — see HPP guide); follow-up operations are type values on POST /api/v1/transactions.
| # | Scenario | Required | Test with |
|---|---|---|---|
| C-01 | Successful card payment (sale) | ✅ | HPP session with capture_mode: sale (default), completed on the hosted page |
| C-02 | Auth-only payment | ✅ | HPP session with capture_mode: authorize — completion materialises an AUTHORIZED transaction |
| C-03 | Explicit capture of C-02 | ✅ | POST /api/v1/transactions with type: CAPTURE + parent_transaction_id |
| C-04 | Cancel an authorization | ✅ | type: AUTH_REVERSAL (or VOID) + parent_transaction_id |
| C-05 | Soft decline handling | ✅ | Decline scenario driven by the amount's cents portion — see Testing |
| C-06 | Hard decline handling | ✅ | Decline scenario driven by the amount's cents portion — see Testing |
| C-07 | Full refund | ✅ | type: REFUND (no amount) against a SETTLED parent |
| C-08 | Partial refund | ✅ | type: PARTIAL_REFUND with amount < original, against a SETTLED parent |
Idempotency scenarios
| # | Scenario | Required |
|---|---|---|
| I-01 | Idempotent retry — same result on replay | ✅ |
| I-02 | Idempotency conflict — different params, same key | ✅ |
Webhook scenarios
| # | Scenario | Required |
|---|---|---|
| W-01 | Receive and verify transaction.captured signature | ✅ |
| W-02 | Handle retry — return 200 on duplicate delivery | ✅ |
| W-03 | Reject stale delivery (timestamp > 5 min) | ✅ |
ACH scenarios (if using ACH)
| # | Scenario | Required |
|---|---|---|
| A-01 | Successful ACH debit | ✅ |
| A-02 | R01 return handling | ✅ |
| A-03 | R10 return handling — stop retrying | ✅ |
Error handling scenarios
| # | Scenario | Required |
|---|---|---|
| E-01 | 401 unauthorized — invalid key | ✅ |
| E-02 | 400 validation_error — malformed request | ✅ |
| E-03 | 200 with state: FAILED and a decline_code — gateway decline | ✅ |
E-03 is not an HTTP error. Both approved and declined outcomes return 200 —
a decline is a normal business outcome, not a transport failure. Discriminate on
state and decline_code. Evidence for this scenario should therefore show a
200 response whose state is FAILED.
How completion is verified
Certification is a check run, not an evidence upload: in the Partner Portal under Integration → Certification, start certification and run the checks. Automated checks verify your sandbox activity directly (the scenarios above are what they look for); some checks are self-attestations you confirm in the portal; a few are ruled by Cresora. You can re-run the checks as you fix gaps.
Keep your own record of each scenario (request, response, webhook received) — it is what lets you fix a failing check quickly — but there is no evidence-file upload.
See Certification overview → for the full process.