Skip to content

docs(avs-for-moto): correct AVS scope, validation and result behaviour - #201

Open
flozanofdez wants to merge 2 commits into
docs-v2from
docs/correct-avs-for-moto-behaviour
Open

docs(avs-for-moto): correct AVS scope, validation and result behaviour#201
flozanofdez wants to merge 2 commits into
docs-v2from
docs/correct-avs-for-moto-behaviour

Conversation

@flozanofdez

@flozanofdez flozanofdez commented Aug 18, 2026

Copy link
Copy Markdown

Why

QA needed confirmed AVS behaviour to close the test suite. Verifying the questions against viscus, cloudapi and hapi-android turned up five claims on the AVS page that don't match the code.

What was wrong

Claim Reality
AVS applies to MOTO Sale, Pre-Auth and Refund (4 places) Sale and Pre-Auth only. operationsWithBilling = ['moToSale','moToPreAuthorization'] (cloudapi); only MotoSaleRequest/MotoPreAuthRequest carry BillingData (viscus); MotoRefundTransaction.isAvsSuitable = false (SDK)
billing with AVS not enabled → "no special handling" Gateway rejects: HTTP 400, error 4070 (MotoBaseService.applyAvsGating). A third state exists — flag never configured → billing dropped, no error
AVS result returned "on both the native SDK and Cloud API" MoToBaseResponse has no addressVerification field and ignores unknown properties, and POST /transactions returns the SDK's result. Only POST /moto/sale surfaces it
TransactionResult.avsResult (EPI agent skill) No such field in hapi-android — it's addressVerification.resultCode
Token sale + enableAvsFields shown as a working option A cardToken sale routes to MotoSaleTransactionWithToken, which has no card-entry screen

What was added

  • Field rules — 20/50 length limits, control-character guard, exact 400 messages.
  • Operations without AVS — billing is never inherited; what happens per path when sent anyway; pre-auth carries it, capture doesn't.
  • What comes back — result-code vocabulary, and that Handpoint never acts on it (a mismatch does not decline).

🤖 Generated with Claude Code

flozanofdez and others added 2 commits August 18, 2026 16:57
The page claimed AVS applies to MOTO Refund, that the merchant flag has no
effect on the gateway, and that the AVS result is returned on both the SDK
and Cloud API. Verified against viscus, cloudapi and hapi-android: billing
is accepted on MOTO Sale and Pre-Authorization only; the gateway rejects
billing with error 4070 when avsForMoto is disabled; and the result code
is only exposed on the back-office /moto/sale response.

Adds the field rules QA needs to write expected results — the 20/50 length
limits, the control-character and long-digit-sequence guards, and the exact
400 messages — plus the result-code vocabulary and the behaviour of billing
on referenced operations.

Co-Authored-By: Claude Code - Claude Opus 5 <noreply@anthropic.com>
Both removed at review. The long-digit-sequence guard and the token-sale
`enableAvsFields` caveat are implementation detail an integrator doesn't
need to reason about; the rules that shape a request stay documented.

Co-Authored-By: Claude Code - Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant