AIM: Holding a payment

[Hurrdat_Timothy]

Alright, I did as much searching as I could, I figure it would be better just to ask about my situation.

I have already developed a platform for endorsed marketing.  In other words, businesses use celebrities to market.

Because of the amounts that these payments may be, we have to accept the business' payment BEFORE we pay the celebrity.

Now, here's the catch.  Our merchant account was granted on the basis that we wait until the celebrity approves their endorsement before we charge the business.  So, to make it simple to understand, here is how our process has to be:

1.  Business selects endorsement type, goes to checkout

2.  Business checkouts with their payment information

3.  Internal filtering processes happen

4.  Business final approval

5.  Celebrity final approval

6.  BUSINESS CHARGED

7.  Celebrity paid

Now, the obvious glaring issue here, is that if the business is declined or has insufficient funds, the celebrity has already approved their endorsement and will expect to get paid.  In other words, our company would have to front that bill and hope to God the business comes through later.

So, after all this, my question becomes, is there a way at STEP 2 above that we can signal via AIM that we want to hold those funds until the celebrity can approve?  Since we can't charge via our merchant account agreement until after the celebrity agrees, we would have to hold a certain amount until we can finalize the sale.

Thanks in advance for responses, and I welcome any alternate methods I could be using as well.

[RaynorC1emen7]

you can do a auth_only for the full amount. and it will hold for (from what I read here) 7 to 30 days depend on the card issuer.

[Hurrdat_Timothy]

Thank you for the response.  This sounds like the type of thing I need.

I will try to figure all of this out (I'm sifting through the SDK/examples, a lot to take in at first), and if I have any more questions I will post them in this thread.  I'll mark the answer as the solution as soon as I have impelmented what I need.

I appreciate the time/help.

[RichardH · Accepted solution]

You can find details about performing an Authorization Only and Prior Authorization and Capture in the AIM Implementation Guide.

Richard

[Hurrdat_Timothy]

Richard,

That guide is beautiful.  I haven't stumbled onto it yet but it has a lot of good information.

I actually am putting e-commerce into two of our sites.  I am continuing to sift/implement the solutions.  I will continue to keep any questions in this thread as I go along.

Thanks so much for all the help.

[Hurrdat_Timothy]

Alright, sorry for the long pause.  Had other fires to tend to in the past week.

Here is another problem:

Apart from the celebrity platform above, we also have a full written site that onboards new clients for a different service we offer.  Thus, we are doing recurring subscriptions.

I followed the API, and I wrote a test application that seems to work.  However, it only works with the test api URL, I.E.

https://apitest.authorize.net/xml/v1/request.api.

Now this may be a silly question, but what would be the post URL for both testing and the live server?  I tried test.authorize.net, however it errors out on the response (Error 405 Method not allowed).  Would it work on the live server when I'm ready to go into live test mode?

Thanks in advance for the support.

[RaynorC1emen7]

https://api.authorize.net/xml/v1/request.api

need production loginID and transactionKey.

[Hurrdat_Timothy]

Raymond,

Just to be clear, you are saying I would need a production login/key to do this on test.authorize.net and the live site?  My developer login/key works for single card transcation tests (on test.authorize.net).  But, if you are saying our production login/key would solve that problem when trying to test recurring transactions, I will give it a shot.

Thanks for the response.

[RaynorC1emen7]

Test loginID/TransactionKey only work on https://apitest.authorize.net/xml/v1/request.api

Production loginID/TransactionKey only work on https://api.authorize.net/xml/v1/request.api

To test on Production run it in testmode and with testCC# to make sure it didn't get charge. No transaction will be create either.

Read

Test Accounts vs. Live Accounts – Which Does What Anyway?

[Hurrdat_Timothy]

Alright, I think I got you.  The AIM version of transactions and the recurring API are two different links.

Makes sense.

For now I am good to go, but I'm sure I will be back!  :)

Thanks again for the help.