TransactKit-Litev1.0.0
TransactKit-Lite testing
Use TransactKit-Lite's browser tester, Postman collection, offline suite, stripe-mock profile, and Stripe Test Mode for distinct verification goals.
Updated
Browser API tester
Run the application and open http://localhost:8080/api-test/index.html. The dependency-free HTML/CSS/JavaScript workbench uses same-origin requests and supports configuration status, Customer create/retrieve, Checkout creation, local Payment lookup, Refund create, and Refund retrieve.
- The page retains useful runtime IDs for the current browser session.
- Checkout creation exposes the Stripe-hosted checkoutUrl when real Stripe is configured.
- Success and cancellation redirects are served from /api-test/success.html and /api-test/cancel.html by default.
- The browser tester does not send signed webhook events and never asks for the webhook secret.
- The tester is a development tool, not host-application authentication or a customer payment UI.
Postman collection
Import TransactKit-Lite-API.postman_collection.json from the repository root. The collection covers all eight public endpoints and defines local example variables for base URL, Customer ID, Payment ID, Refund ID, business reference, attempt reference, refund reference, and Stripe signature.
Default automated suite
The standard suite is offline and requires no Stripe key, Stripe CLI, MySQL, browser, or Docker. It covers context startup, no-credential behavior, request/DTO validation, ProblemDetail mapping, Customer/Checkout/Payment/Refund services, payment lifecycle rules, transaction rollback behavior, webhook verification and deduplication, retryable claims, concurrency, and local projection transitions.
./mvnw clean verify.\mvnw.cmd clean verifyOptional stripe-mock contract profile
Start a local stripe-mock process on port 12111, then opt into the Maven profile. The repository's documented Windows launcher is an example local installation path, not a bundled TransactKit file.
- The profile uses dummy key sk_test_123 and the official StripeClient.
- It verifies selected Customer, Checkout, and Refund contracts plus SDK serialization/deserialization and local H2 writes.
- STRIPE_API_BASE can route a manually started app to the mock, but it must never be set in production.
- stripe-mock is stateless and does not prove hosted Checkout, card processing, PaymentIntent/refund lifecycle behavior, webhook delivery, realistic declines/errors, or Dashboard synchronization.
C:\stripe-mock\start-stripe-mock.cmd
.\mvnw.cmd -Pstripe-mock clean verify./mvnw -Pstripe-mock -Dstripe.mock.url=http://localhost:12111 clean verifyStripe Test Mode
Use Stripe Test Mode after the offline and contract suites pass. It is the verification layer for the Stripe-hosted page, real test payment methods, synchronous and asynchronous outcomes, Dashboard state, webhook signatures, delivery retries/order, and end-to-end refund behavior.
- Complete a successful Checkout and confirm the local Payment becomes PAID.
- Exercise failed and supported asynchronous payment behavior.
- Deliver all seven handled Checkout/refund event types.
- Redeliver an event and verify duplicate acknowledgement without a second state change.
- Create a partial refund, another partial refund, and a full remaining refund.
- Confirm the configured success and cancellation redirect pages.
- Compare Stripe Dashboard state with the local projection.
What each layer proves
| Layer | Strongest signal | Does not prove |
|---|---|---|
| Unit/MVC/integration suite | Application logic, validation, transactions, persistence, deterministic webhook behavior | Live Stripe behavior |
| stripe-mock | Selected request shape and SDK contract compatibility | Payment processing, stateful lifecycle, webhooks, or realistic Stripe errors |
| Stripe Test Mode | Hosted and Stripe-managed integration behavior | Production traffic, host authorization, operational readiness, or business fulfillment correctness |