topic Re: Only Charge at shipment time in Integration and Testing

Only Charge at shipment time

fantomknight — Fri, 12 Nov 2010 07:42:43 GMT

He guys,

I am new to Authorize.net and I have a quick good question here :)

I know that my gateway will automatically submit a batch of successful transactions daily at a predefined time for settlement. Now lets say I want to just authorize the user's card but actually charge them at the shipping time. How do I do that ? Is there like a status before "pending for settlement" status that I can set it, like "sucesful verified" or something like that only. And then I could flip the status of the transaction to "pending for settlement" later when I ship out the products ?

Please let me know your solution to this common problem.

Thanks!

Re: Only Charge at shipment time

soundcommerce — Fri, 12 Nov 2010 13:21:10 GMT

Greetings,

If you plan to ship the product within 30 days, you may perform what is called an "authorize only" (AUTH_ONLY) submission to the API.

After shipping the product,simply login to Authorize.Net and click the "capture" button to capture/settle the transaction.

You may also programmatically capture the transaction through the Authorize.Net API (PRIOR_AUTH_CAPTURE).

Thank You!

Re: Only Charge at shipment time

fantomknight — Thu, 18 Nov 2010 06:06:36 GMT

ahh I see got it. Thanks

2 more questions:

1) any way to automatically renew an AUTH_ONLY transac by its id before it expires ?

2) I see we can only PRIOR_CAPTURE an AUTH_ONLY transac on the same or smaller amount.

In the event a customer added some more items, I would like to PRIOR_CAPTURE to a larger amount than originally submitted.

Any problem with AUTH_ONLY with a very large amount, lets say double the submitted total by customer, to leave room for additional items

on PRIOR_CAPTURE ? Would AUTH_ONLY a high amount would increase the chance to fail authorization step ?

does the amount at AUTH_ONLY matter at all?

Thanks!

Re: Only Charge at shipment time

stymiee — Thu, 18 Nov 2010 14:14:14 GMT

1) No. You would need to do a new AUTH ONLY.

2) Using AUTH ONLY freezes the funds on a customer's credit card. So by freezing more then they requested not only do you limit their access to their own money, but you risk a chargeback because you froze more then you were allowed to. Only AUTH ONLY the amount you need. If their purchase is more then you orginially charged for ask for a new payment.

Re: Only Charge at shipment time

fantomknight — Sun, 21 Nov 2010 01:58:25 GMT

then what about expiration date? They dont look validated either. As long as I just need to enter some dates isnt it? Or some option i need to turn on for this validation ?

Thanks!

Re: Only Charge at shipment time

stymiee — Sun, 21 Nov 2010 14:56:43 GMT

Invalid or expired expiration dates do not necessarily mean a transaction will be declined. It's up to the issuing bank to decide if they will decline the transaction if the card is expired or an incorrect expiration date is provided. You will see transaction approved even with made up expiration dates. This doesn't mean it is a good practice as you open yourself up to chargebacks and will automatically lose with no recourse for recovery of funds. You also leave yourself up to prosecution for credit card fraud.

Re: Only Charge at shipment time

fantomknight — Tue, 23 Nov 2010 07:25:58 GMT

I do understand that "it is a good practice as you open yourself up to chargebacks and will automatically lose with no recourse for recovery of funds. You also leave yourself up to prosecution for credit card fraud." However, as you said its up to the issue bank to decide, there is nothing I can do on my side isnt it? I sure will provide the expiration date / year input for customers but once I submit them to the gateway I have no control if they will be validated all the time. And just to confirm there is no setting in my gateway to enhance this checking. So looks like all hope for the best in this expiration date thingy ?

Re: Only Charge at shipment time

stymiee — Tue, 23 Nov 2010 15:10:26 GMT

If your user submits an incorrect expiration date that's just an error on their side and only a potential problem in-so-much-as it may result in a declined transaction. The bigger issues come into play if you intentionally submit an incorrect expiration date in the hopes of getting a transaction approved.

And there is no way to know if an expiration date is correct until you run a transaction. And even then you probably won't get a detailed response back to let you know the expiration is incorrect. But incorrect expiration dates occur infrequently and declines for it being incorrect occurs even less so I wouldn't worry about it too much.

Re: Only Charge at shipment time

TSdotNet — Tue, 23 Nov 2010 15:55:27 GMT

" So looks like all hope for the best in this expiration date thingy"

when it really comes down to it the whole credit card system is based on hope - hope that the details are correct - hope that the card has not been cancelled by its issuer - hope that the customer is who they say they are....

Seems to me that it is always a case of doing the best with the information you are given / have access to. And with that in mind, we draw lines of good practice and reasonable faith/hope.

Re: Only Charge at shipment time

fantomknight — Tue, 23 Nov 2010 15:56:33 GMT

Another issue I have is to charge customer transaction fee but there are qualified and non qualified transactions so I cant have a fixed rate. Is there anyway to know the transaction is qualified or none qualified before actually charging it ? I dont mind give them server two calls if needed.

Thanks!

Re: Only Charge at shipment time

TSdotNet — Tue, 23 Nov 2010 15:59:45 GMT

Any chance of adding in a transaction fee as default, then refunding after - once you have verified the status?

Re: Only Charge at shipment time

stymiee — Tue, 23 Nov 2010 16:55:02 GMT

FYI, adding the processing fee is against Visa and MasterCard guidelines and can get you shut down. If you're going to do it you either need to label it something else or blend it into their costs.

Re: Only Charge at shipment time

TSdotNet — Tue, 23 Nov 2010 17:00:59 GMT

:smileysurprised: thank goodness you said that :smileyhappy:

Re: Only Charge at shipment time

fantomknight — Thu, 25 Nov 2010 03:03:25 GMT

ohh I've never known that. Can I just simply call it "transaction fee" and explain that its fee to process card transaction ? Is it still against Visa or Master processing guideline ?

Re: Only Charge at shipment time

fantomknight — Thu, 25 Nov 2010 03:16:22 GMT

Also do you guys know if a merchant gets charged for a declined or an invalid transaction ?

Do we get charged for all authorized attempt or just successful settled ones ?

Thanks!

Re: Only Charge at shipment time

stymiee — Thu, 25 Nov 2010 15:30:37 GMT

@fantomknight wrote:
ohh I've never known that. Can I just simply call it "transaction fee" and explain that its fee to process card transaction ? Is it still against Visa or Master processing guideline ?
Also do you guys know if a merchant gets charged for a declined or an invalid transaction ?

Do we get charged for all authorized attempt or just successful settled ones ?

Thanks!

You can't call it a transaction fee. That's exactly what they don't want you to do. If you are going to charge this fee you need to label it something that in no way ties it to the payment.

Unless you have a great deal with your merchant account provider you get charged for every transaction. This includes your merchant account provider and Authorize.Net.

Re: Only Charge at shipment time

fantomknight — Thu, 25 Nov 2010 23:21:58 GMT

got ya.

Do you know how they charge for a declined transaction ? Lets say i have a bad customer who repeatedly attempted to pay a cart of $5000 - 10 times . All 10 times were declided,. Lets say my rate is 2.5% + 30c . Will I owe them 2.5% + 30c each for all those 10 declined 5000s ? That does not make sense at all.

Any idea here?

Re: Only Charge at shipment time

fantomknight — Fri, 26 Nov 2010 22:48:32 GMT

Also any idea on how to protect your self against fraud and having shipping addresses different from billing addresses even though all those information was submitted by buyers ? I see Amazon and many other companies allow consumers to have different shipping and billing addresses . How do they protect themselves against fraud chargebacks ? Any idea? I live-chatted with a authorize.net rep and they said that in their experience, you have zero chance .... is it that depressing?

Re: Only Charge at shipment time

stymiee — Sat, 27 Nov 2010 15:16:07 GMT

@fantomknight wrote:
got ya.

Do you know how they charge for a declined transaction ? Lets say i have a bad customer who repeatedly attempted to pay a cart of $5000 - 10 times . All 10 times were declided,. Lets say my rate is 2.5% + 30c . Will I owe them 2.5% + 30c each for all those 10 declined 5000s ? That does not make sense at all.

Any idea here?

They only charge the percentage portion of your rate on successful transactions. Declined transaction only incur a transaction fee. This is to cover the cost of processing the transaction even though it was declined.

Re: Only Charge at shipment time

stymiee — Sat, 27 Nov 2010 15:19:47 GMT

@fantomknight wrote:
Also any idea on how to protect your self against fraud and having shipping addresses different from billing addresses even though all those information was submitted by buyers ? I see Amazon and many other companies allow consumers to have different shipping and billing addresses . How do they protect themselves against fraud chargebacks ? Any idea? I live-chatted with a authorize.net rep and they said that in their experience, you have zero chance .... is it that depressing?

Use your brains. The vast majority of fraud with mismatching shipping and billing addresses are obviously fraudulent but businesses are so eager for sales they'll accept them anyway. If the billing and shipping addresses don't match check your fraud indicators (AVS, CVV, call the customer, etc.). The more of them that are positive the more likely it is fraudulent and you should refund the transaction.