I thought this was the case, however I created a workaround to capture full billing data:
- Set 'data-billingAddressOptions' to show = false, required = false in AcceptUI config
- Set 'data-acceptUIFormHeaderTxt' to 'Payment Information (Step 2 of 2)'
- Create a similarly styled modal to the AcceptUI modal and title it 'Billing Information (Step 1 of 2)'
- In Billing Information modal, place first name, last name, address, city, state, zip fields with 'auth_billing_field' class, and a Payment Information button at the bottom that links to AcceptUI.js, disable the button by default. Add an onclick handler to this button that closes the Billing Information modal.
- Use JQuery/JS to detect keyup event on 'auth_billing_field' class inputs. When the event fires, iterate the 'auth_billing_field' inputs and check for validity. If they are valid, remove the disabled property from the Payment Information button.
- When the customer clicks the Payment Information button, the Billing Information modal will close, and the AcceptUI form will present itself with Card ID, Expiry and CCV fields.
When the customer submits the AcceptUI form and you receive the payment token back from Authorize.net, package the token with all of the other billing information you've collected in your Billing Information modal and create a customer payment profile via createCustomerProfileRequest and createCustomerShippingAddressRequest. Use your payment profile ID as the payment information for the createTransactionRequest.
This method will satisfy AVS, as the test transaction that is processed during createCustomerProfileRequest will be checked against all of the billing information you've supplied rather than only the ZIP code.
If you take the time to style your modal, fields and button, it appears to be seamless to the end user.
