cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted and Sales Tax calculation

Sales tax calculations often depend on the location of the purchaser. For example, if I don't have a nexus (or "presence") in a particular state, I don't need to charge sales tax to purchasers in that state. But I do need to charge sales tax if the purchaser is in the same state as my store.

Since I'm using the Accept Hosted iframe checkout form, I don't know the purchasers address prior to checkout through Authorize.net. How can I apply sales tax to the purchase price?

I would collect the purchasers address on my end and then pass it to the Accept Hosted form when I request the token. But if I include the shipping/billing information in the Authorize.net transaction, it gets included in the checkout form and the customer has an opportunity to change their address after tax has been applied. If I don't include the billing/shipping information in the form, it doesn't appear in the transaction.

Please advise on how to handle this.

Thanks

jm_dgsdev
Member
1 ACCEPTED SOLUTION

Accepted Solutions

There's one further workaround that's a little more convoluted, but still might get you what you want.

 

My guess is that for tax calculations, it's the shipping address that's important. The billing address is useful for card verification, but where the product is shipped would determine taxing, right? So, that's the address you wouldn't want changed after the tax calculation.

 

Using our Customer Profiles feature and the Accept Customer hosted forms, you could first create a profile using the shipping address you've previously collected, but without billing information. Then, you could call our hosted addPayment form to have the customer add payment information to the profile (with or without billing address, your call). Then, when they submit that billing information, you charge the profile for the total you've previously calculated.

View solution in original post

5 REPLIES 5

Hi @jm_dgsdev,

 

Unfortunately you're correct in your conclusion that there's no way to send the address without it also being editable.

 

I'll ensure that our development is aware of this limitation so that it can be considered for future improvement. In the meantime, there are a couple of possible workarounds.

 

1. For whatever address your customer is entering that allows you to calculate tax, store that address on your side, and sync it up with the transaction later (perhaps by retrieving transaction info from our records and matching them up on your side).

 

2. You could use Accept.js which lets you create a form to do exactly what you want, and then just have the customer's browser send the payment information directly to us to be tokenized so that you can use this tokenized information in your transaction request.

 

Maybe neither of these are desirable to you, but I wanted to at least recommend a couple of possible solutions.

Aaron
All Star

There's one further workaround that's a little more convoluted, but still might get you what you want.

 

My guess is that for tax calculations, it's the shipping address that's important. The billing address is useful for card verification, but where the product is shipped would determine taxing, right? So, that's the address you wouldn't want changed after the tax calculation.

 

Using our Customer Profiles feature and the Accept Customer hosted forms, you could first create a profile using the shipping address you've previously collected, but without billing information. Then, you could call our hosted addPayment form to have the customer add payment information to the profile (with or without billing address, your call). Then, when they submit that billing information, you charge the profile for the total you've previously calculated.

Aaron, thanks for your replies and for passing my concerns to the development team.

Please see my notes below:

 

@Aaron wrote:
1. For whatever address your customer is entering that allows you to calculate tax, store that address on your side, and sync it up with the transaction later (perhaps by retrieving transaction info from our records and matching them up on your side). 

Thats definitely a possibility. One disadvantage is that the transactions stored on ANET won't have any associated billing or shipping address. But that may not matter, depending on how merchants choose to review, settle, and archive their orders/transactions. Also, it seems like this will defeat any fraud detection systems on the ANET side that rely on checking addresses.

 

 

@Aaron wrote:
2. You could use Accept.js which lets you create a form to do exactly what you want, and then just have the customer's browser send the payment information directly to us to be tokenized so that you can use this tokenized information in your transaction request.

This seems like a reasonable idea, but the PCI assessment team for one of my clients has advised to use Accept Hosted as opposed to Accept.js. Apparently, they see an advantage for simplifying PCI compliance and they don't want a payment form displayed directly on my site at all.

 

 

@Aaron wrote:
Using our Customer Profiles feature and the Accept Customer hosted forms, you could first create a profile using the shipping address you've previously collected, but without billing information. Then, you could call our hosted addPayment form to have the customer add payment information to the profile (with or without billing address, your call). Then, when they submit that billing information, you charge the profile for the total you've previously calculated. 

I am leaning toward using Customer Profiles. It seems that this will allow me not only to better validate addresses before sending them to ANET, but also to develop a more robust application to manage customer profiles, which I imagine some of my clients will love. One issue I'm encoutering is how to protect profiles when customers use "guest checkout" on my site. I've posted this issue as a separate topic here:

 

https://community.developer.authorize.net/t5/Integration-and-Testing/Customer-Profile-authenticate-u...

I wanted to update this with a couple of more points

 

We've released some enhancements to the Accept Hosted form that allow address information submitted in the token request to persist even if it's not displayed on the form. This enables you to use AVS or do other things that might require the address to be stored on our system without risk that the customer will change the address on the hosted form. That can possibly change how you might approach scenarios like this.

 

A bigger change for your scenario is the hosted form that you can call through Accept.js. As detailed in the latest rev of the Accept.js documentation, there's now a way to call up a hosted form using JavaScript to collect the payment information. This gives the same PCI-DSS compliance profile as Accept Hosted but with less of the hassle (in my opinion anyway). With this available, I would probably modfiy my initial answers to you somewhat.

 

It may be too late to make a difference in this case, but wanted to make sure you saw it nonetheless.

 

 

A paid product that automatically calculates the tax on your transactions without the need to define the rates and rules. Fees only apply after you’ve added at least one location where you’re registered to calculate and remit tax. More Tips Here 

Louise92
Member