TRUSTWEAVE SDK · 7 SEPTEMBER 2026
Payment validation gap closed
Fresh intent-module evidence for the local working tree. The broader production-readiness score remains 8.7 / 10.
TW-PV-01 · Medium · Fixed and verified
Immediate-payment verification checked only that an amount existed. Autonomous payments could also bypass the amount checks when the mandate had no optional amount-range constraint. Real signed chains containing negative, quoted, fractional, overflowing, null or collection amounts—and malformed currencies—were accepted.
The shared payment validation now requires a non-negative integer within signed 64-bit range and an uppercase three-letter currency string in both modes. Currency syntax validation does not establish ISO currency membership. Valid zero, positive and maximum integer amounts remain accepted.
All 36 signed regression vectors now pass: 6 valid boundary cases and 30 rejection cases. Before the fix, 26 of those rejection assertions failed. No public API or persisted schema changed. Callers sending previously tolerated malformed values must correct their inputs.
Complete module validation
The full intent suite, module lint and API compatibility check passed. The 87 cases executed in this run; the build also reused unchanged compilation tasks. The earlier Docker interruption no longer blocks local module evidence.
| Suite | Tests | Failures | Skipped |
|---|---|---|---|
| ChainVerifierKnownAnswerTest | 8 | 0 | 0 |
| CheckoutTrustTest | 3 | 0 | 0 |
| ConstraintCheckerTest | 13 | 0 | 0 |
| ConstraintValidationRegressionTest | 4 | 0 | 0 |
| CrossStackConformanceTest | 1 | 0 | 0 |
| Es256AlgorithmPinningTest | 3 | 0 | 0 |
| IntentOperationsExerciseTest | 1 | 0 | 0 |
| IssuanceRoundTripTest | 10 | 0 | 0 |
| LineItemMatcherTest | 5 | 0 | 0 |
| PaymentSchemaValidationTest | 36 | 0 | 0 |
| PostgresIntentLedgerTest | 1 | 0 | 0 |
| RecurrenceRulesTest | 2 | 0 | 0 |
Existing interoperability checks also passed: six Python-issued cases verified in Kotlin, plus eight Kotlin-issued positive/adversarial checks in the pinned Python reference. No expanded conformance coverage is claimed.
Commands, counts and source hashes · Build log · Immediate reference results · Autonomous reference results
Database failure and restore exercised again
The loopback component test sent 100 requests at concurrency 8: 50 were authorized and 50 rejected. It stopped its primary database, observed a 503/storage-failure signal, restored a pg_dump backup into a separate PostgreSQL instance, compared complete ledger rows, and rejected replay of all 50 restored transactions.
Measured load duration: 1352 ms; handler p95: 191 ms; restore exercise: 2232 ms. These are local component measurements with pre-authorized fixtures and a quiesced backup, not production throughput, RTO, RPO or PITR guarantees. Test containers were cleaned up.
Score retained: 8.7 / 10
The same six-category rubric is retained from the preceding assessment. This fix and renewed module evidence do not establish the missing production qualifications. These scores are engineering judgment, not certification.
| Category | / 10 |
|---|---|
| Security and access control | 9.0 |
| Observability and diagnosability | 8.0 |
| Reliability and scale | 9.0 |
| Configuration and data | 9.0 |
| Deployment and release | 8.5 |
| Testing and documentation | 8.5 |
Category sum 52 / 6 = 8.6667, rounded to 8.7. No new full-SDK coverage measurement was made.
- Qualify managed signing, live provider access and durable key-loss recovery against an identified non-production resource.
- Complete independent interoperability for every supported profile, including merchant trust and stateful constraints.
- Exercise the deployed host, payment journal, PITR system and pager with agreed load and availability targets.
- Validate the exact committed SDK/SaaS pair in hosted CI and verify the actual published artifact.