val.town: role and evidence
A way to ship websites, automations and tools to live URLs. Suitable as an application-hosting candidate, not evidence of built-in payment settlement.
Evidence, not endorsement
A research and planning tool, not a vendor certification. Sources describe specific products, not every service offered by a company. Unknown means not established by the sources reviewed, not unsupported. grug402 sandbox tests do not test these vendors. Operational owners are suggested team contacts, not legal liability assignments.
Editorial review: 2026-10-08. Evidence older than 90 days needs rechecking; source check dates are not release dates.
Product and roles
Operator: Val Town. Product scope: Val Town deployments and agent connections.
App platforms: Where does the application run? Handoff: Application code → authenticated tools and payment middleware. Suggested owner: Application engineering.
Prerequisites to confirm
Check runtime, secret handling and request limits for your application.
Review agent connection permissions.
Discovery
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Delegated authorization
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Retail checkout
Not applicable: not assessed for this participant's listed role.
Paid API / tool
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Settlement
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Deployment
Documented: Val Town describes instant deployments of websites, automations and tools, with agent connections.
Operational controls
Unknown: not established by the reviewed sources. Ask the provider; this is not a failed test.
Relevant sandbox tests — not vendor results
These are controlled grug402 scenarios. A passing sandbox request does not certify a company, integration, checkout or refund process.
- P1: A payment that completes — Establish a baseline before diagnosing failure cases. Suggested owner: Payments engineering.
- P1: Bind approval to the right service — A payment must not be redirected to an unexpected resource host. Suggested owner: Agent product and security.
- P1: Retry without a duplicate charge — Lost responses should not cause the same purchase intent to be paid again. Suggested owner: Application engineering.
- P1: Handle paid-but-not-delivered — Settlement can succeed while the application fails to deliver. Suggested owner: Payments and customer operations.
- P2: Resolve an uncertain settlement — A server error does not establish whether money moved. Reconcile before retrying. Suggested owner: Payments operations and facilitator operator.
- P1: Establish safe edge behavior — Challenges and personalized paid responses need deliberate cache controls. Suggested owner: CDN and application engineering.
- P2: Avoid stale payment instructions — A cached challenge can advertise an expired quote or outdated payment terms. Suggested owner: CDN and payments engineering.
- P1: Prevent paid content leaking from cache — A shared cache can serve one payer's content to another visitor. Suggested owner: CDN and security.
- P2: Allow valid payment credentials through — Security policy may reject a legitimate payment retry. Suggested owner: Network and security.
- P2: Coordinate edge and settlement timeouts — A timeout can leave the buyer unsure whether the service was paid. Suggested owner: Network and payments operations.