cancel
Showing results for 
Search instead for 
Did you mean: 

How do I create non-structured future payments

(I'm sorry if this is answered clearly somewhere, I couldn't find it)

 

We want to be able charge a customer 4 times, on specific dates that span nearly 10 months from the first charge to the last. What's the best way to do this?

 

It doesn't look like any APIs have the ability to schedule payments for the future so I thought using the CIM XML API to create a customer profile would do the trick. However in order to make those 4 payments at the allotted times I'll have have the card's CCV since we check against it, that means I have to store CCVs locally for more than a year (which breaks PCI Compliance). Do I have any options here?

 

Thank you for any advice!

drewgg
Member
1 ACCEPTED SOLUTION

Accepted Solutions

You don't need CCV except when setting up the billing profile or making changes to it. CIM is the way to go.

View solution in original post

TJPride
Expert
9 REPLIES 9

You don't need CCV except when setting up the billing profile or making changes to it. CIM is the way to go.

TJPride
Expert

Thank you for the response TJ. I didn't notice yesterday that the "Prior Authorization and Capture" version of "createCustomerProfileTransactionRequest" didn't require a CCV. So I should use the CCV when I set up the profile and then use the "profileTransPriorAuthCapture" to create the  transactions. Makes sense, thanks!

createCustomerProfileTransactionRequest

Actually, you'd just have your routine check every day to see if they're due, and if they are, run an AuthCapture. There's no need to authorize and then capture later, unless the first charge is always within 7 days of signing up and you don't want to spend the extra transaction fee on validation mode (which charges them a cent to verify their credit card info and then immediately voids).

Hmm. Maybe the terms are confusing me or maybe I'm not getting it. This is my current understanding:

 

When the customer registers initially (which may be weeks or months before the first scheduled charge) I am creating a profile (via "createCustomerProfileRequest") which includes a Payment Profile (ie, <paymentProfiles>, <billTo>, <payment>) and a Shipping Address profile (ie, <shipToList>). I save the 3 profile IDs to a database.

 

I then have a routine (cron) that checks for a due date and when it's time it charges the customer's card (via "createCustomerProfileTransactionResposne" using "Prior Authorization and
Capture" fields) using the 3 saved profile IDs.

 

Am I on track?

 

 

Prior authorize and capture is only for if you run an authorize first against the billing profile to reserve the money for up to 7 days. It's generally used when an order is initialized immediately but the money is only taken out when the products ship a few days later. If the products don't ship or if the customer cancels, the authorize is just allowed to run out. Setting up a billing profile is totally different from authorizing a transaction.

 

Short version - you want AuthCapture in this situation. PriorAuthCapture would require a transaction ID, which would mean you already set up the transaction previously using AuthorizeOnly or AuthOnly or whatever it is.

So I would use the AuthCapture but leave out the CCV. The CCV is would normally be required for AuthCapture because my account is set to reject if the CCV doesn't match, however, because I included the CCV when I initially created the Payment Profile I don't need to include it in my AuthCapture. Correct? (I hope it is because I don't want to waste any more of your time ;)

You don't need to include any credit card info when charging against a CIM billing profile. That's the whole point of having a billing profile.

Yep. That's what got me so confused. When I was going through the API Guide for AuthCapture and read the "This field is required if the merchant would like to use the CCV security feature." line for the CardCode field I thought it meant that I had to use it even if I use a payment profile earlier. It didn't make sense though. Thanks for the help clearing me up!

No problem, glad to help.