Cybersource Developer Community Cybersource Developer Community

simeyla · ‎06-14-2017

@RichardH Can we please get some documentation!

I have a tonne of questions:

First of all, I use CIM and no ARB. I process 'subscription' payments via customer payment profiles manually using my own scheduler about every 2 months.

You say to check the developer blog, but I don't see a single article!
What legal disclaimer do we need to give our customers when we use this service?
Expiration date updates sound pretty straightforward, but how do PAN updates work? What if a criminal stole a card number and used it on our site and then the card was cancelled by the customer. Would the account updater update the card and then we would end up charging the new card illegally? Or does chargeback kick in and prevent account updater from updating.

Does the updater really run only once a month?
That makes no sense to me. If someone loses a card on 1st month and it doesn't update until the 15th then how does that customer get updated?
With CIM profiles that the customer has 'cancelled' with us - I assume those will still get updated and the fee charged. Is there a way to mark a CIM profile as 'inactive' for the purposes of updating - or do we have to delete it outright? Deleting it is not a favorable option because customers often come back to re-activate.

Can we manually request an update if a particular transaction fails?
I don't want to run all payment profiles through the updater as many of them are inactive.

Do we use the CyberSource API? http://apps.cybersource.com/library/documentation/dev_guides/Account_Updater_UG
Or is there a new Authorize.NET API coming?

Thanks! This is a fantastic feature that will make me popular with my boss - but there's just too many unanswered questions.

Aaron · ‎06-14-2017

Hi @simeyla,

Those are all good questions you're asking. I'll answer some and have to get back to you on some. Account Updater is in sort of a soft launch phase where all of the technical updates are completed, and everything's ready for merchants to sign up, but mass communication regarding its availability hasn't really begun. We'll start that in the coming weeks as a coordinated effort among all departments. Until then, there may be a few spots where info is scarcer than we would like.

You say to check the developer blog, but I don't see a single article!

We do intend to have a blog post that gives some developer-specific info, but that's not ready just yet. Did we say somewhere in this thread that we would have one? If so, sorry for not following up on that yet.

What legal disclaimer do we need to give our customers when we use this service?

I'm not aware of any that's needed. I'll ask around here, but as usual, if you ask us a legal question, we'll probably suggest you ask your own legal counsel.

Expiration date updates sound pretty straightforward, but how do PAN updates work? What if a criminal stole a card number and used it on our site and then the card was cancelled by the customer. Would the account updater update the card and then we would end up charging the new card illegally? Or does chargeback kick in and prevent account updater from updating.

The updates come from the card schemes themselves (i.e. Visa or MasterCard) who get the information from the banks issuing the cards. I would like to say that the process is well-developed enough that a merchant who got a chargeback on a given card is then blocked from updating the card, but I don't actually know if that's true. That's one I'll find out for you.

Does the updater really run only once a month?
That makes no sense to me. If someone loses a card on 1st month and it doesn't update until the 15th then how does that customer get updated?

Yes, indeed, the updater runs once per month. I don't know yet whether that's the same day for everyone, or on the month anniversary of the signup, or just a random date assigned to each merchant. I'll find out.

With CIM profiles that the customer has 'cancelled' with us - I assume those will still get updated and the fee charged. Is there a way to mark a CIM profile as 'inactive' for the purposes of updating - or do we have to delete it outright? Deleting it is not a favorable option because customers often come back to re-activate.

Can we manually request an update if a particular transaction fails?
I don't want to run all payment profiles through the updater as many of them are inactive.

No good answer to these two, I'm afraid. If you don't want a profile to be updated, you'll have to delete it. Think about it this way, though: You're keeping the profile in existence to save the customer some effort. If you keep the profile existant but not updated, the customer's got a problem when they reactivate. If it's important enough to keep the payment info on file, it might also be important enough to update it.

In a perfect world, "inactive" profiles wouldn't get run through Account Updater, and if/when a customer reactivates, you could just update their payment profile(s) on demand. Unfortunately, that's just not how it works right now.

I'd encourage you to post this one (along with the other answers you may not like) onto our Ideas Forum where others can take a look, contribute feedback, and vote for new features.

Do we use the CyberSource API? http://apps.cybersource.com/library/documentation/dev_guides/Account_Updater_UG
Or is there a new Authorize.NET API coming?

There is a new Authorize.Net API here (yay!). It's just that the documentation hasn't gone up to the public web site yet (boo!). The API is limited to summary and detail reporting of a particular month's run (right now). This isn't a substitute for real documentation, but I'll post a couple of example requests to get people started. (Samples in XML and JSON formats. Endpoints are the same as the rest of our API. The only parameters required in these requests are merchantAuthentication and month. If you use the modifiedTypeFilter on the details request, the possible values are all, updates, and deletes.

<getAUJobSummaryRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>{{loginId}}</name>
        <transactionKey>{{transKey}}</transactionKey>
    </merchantAuthentication>
    <refId>123456</refId>
    <month>2017-06</month>
</getAUJobSummaryRequest>

<getAUJobDetailsRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
    <merchantAuthentication>
        <name>{{loginId}}</name>
        <transactionKey>{{transKey}}</transactionKey>
    </merchantAuthentication>
    <refId>123456</refId>
    <month>2017-06</month>
    <modifiedTypeFilter>all</modifiedTypeFilter>
    <paging>
	<limit>100</limit>
	<offset>1</offset>
    </paging>
</getAUJobDetailsRequest>

{
	"getAUJobSummaryRequest": {
		"merchantAuthentication": {
			"name": "{{loginId}}",
			"transactionKey": "{{transKey}}"
		},
		"refId": "123456",
		"month": "2017-06"
	}
}

{
	"getAUJobDetailsRequest": {
		"merchantAuthentication": {
			"name": "{{loginId}}",
			"transactionKey": "{{transKey}}"
		},
		"refId": "123456",
		"month": "2017-06",
		"modifiedTypeFilter": "all",
		"paging": {
			"limit": "100",
			"offset": "1"
		}
	}
}

simeyla · ‎06-15-2017

@Aaron Thanks for your quick answers. I realize it's hard to find a balance between releasing new stuff and having it fully documented so I look forward to following this thread.

Glad to see an API is coming along. Do you know if there will (or definitely won't) be a way to manually request updates for certain profiles. It sounds like at this point you don't know but I see that the CyberSource API has 'harvest updates' which sounds like the full blown auto-update, as well as a 'batch update' API for specific profiles. The 'batch update' feature would solve all my problems - such as card numbers changing 'between updates' and not running updates for inactive profiles.

Right now it looks like I have to decide between 3 options:

1) Just let it run as-is with all my profiles (sounds very dangerous and potentially expensive).

2) Delete inactive profiles older than 2 subscription periods. Then enable auto-updater. Customers out of this range would need to re-enter their card info if they ever came back.

3) Wait for an API to allow me to update specific profiles.

4) Combination of 2+3

If option 3 is coming soon I would wait, but if you can tell me this isn't likely to happen soon then I would do option 2.

Another business reason for option 3 is that about 50% of our customers aren't even in the subscription service. So over time updating their profiles would be an added expense for no gain. We have many customers that come back after trying the product, and so obviously having card-on-file for them is advantageous.

Hopefully you are right about the 'smart' detection of a chargeback to prevent auto-update to that merchant. We really get a noticable hit after an event like the 'Target' card theft - but if someone uses our site to try to test if a card is still valid then we don't want to compound the chargeback problem!

Other small questions :

* Does this only work for Visa cards?

* Are there any 'secret' features we can take advantage of? For instance might there be a way to only auto-update profiles from the last 6 months. This would mean I wouldn't have to delete old ones. Seems like an example of a very simple feature that would be very beneficial.

* Are you aware of any ball-park statistics on how many cards this would 'recover' based on industry averages?

* Can you confirm that the CyberSource API is of no use to Authorize.NET customers. I always get confused about the relationship between the two companies. I keep mentioning it because it seems to have all the features I need - including the concept of an 'inactive' / 'cancelled' profile which would prevent auto-updating. If a customerPaymentProfile could be marked 'inactive' to prevent auto-updating that would be a HUGE benefit. This 'perfect world' scenario you mention only requires you guys to add a Boolean value to a profile - for huge benefit.

* Will webhooks be part of your API? I'd love to get instant updates so I can update what someone would see if they log into their account.

* If you can find out *when* the update runs it would be helpful so I know when to pull a report.

Thanks again and look forward to getting up and running with this. I feel a bit like a cat who has been given a can of cat food but with no way to get into it!

Aaron · ‎06-16-2017

Hi @simeyla

Just FYI, I moved this thread into the main integration forum. These are all good questions you're asking and I wanted to give the info here more visibility for anyone who might be looking for more info in the future.

Secondly, if at any point you want to arrange a call on this with me and/or a product manager, I'd be happy to help. Just shoot me an email at aawright@authorize.net.

Thirdly, some rapid-fire responses to your questions:

There is no way at present to have account update run on anything less than your full set of profiles. Running on subsets of profiles is definitely something planned, but I can't commit to any specific timeline for possible implementation of those feature. The other enhancements you suggest, like marking profiles inactive, are all good ideas, we can look at as well.
Our service will update Visa and MasterCard cards at present, with future plans for other card types.
No "secret" features at present, no. What we currently have available is the monthly update service for all your profiles.
I don't have anything in front of me regarding statistics. I know that's something they're preparing for the wider communications efforts, so I'll look into that. I do know that for almost all merchants the very first batch of updates will be a lot larger than subsequent runs, since there will be months or years worth of updates waiting in the wings. Subsequent updates will only be a fraction of the entire base of profiles, but what that fraction is will be something I'll have to get back to you on.
The CyberSource API is of no benefit to you, unfortunately. We're both part of the larger Visa merchant services family, but the front end APIs to both our systems are completely separate. We have some shared back end services, and we work closely with their teams on those services and other business issues, but there's no way to have that API do anything to your Authorize.Net account.
Having Webhooks notifications would be great, especially if updates weren't batched the way they are now. Right now with the current monthly run of all the profiles, about the only Webhook notification we could implement is net.authorize.accountupdater.HeyYourMonthlyUpdateProcessHasJustRun, or alternatively a whole bunch of notifications about individual cards being updated all firing off one after another once a month. The first scenario that's just a notification of the monthly process finishing could be useful, though, to let you know when to query the API for updates. I'll make sure that's suggested.
Still needing to get back to you on when the job is run each month. Stay tuned.

Aaron · ‎06-16-2017

Some of the questions (i.e. when does it run) are now answered in a support KB document:

https://support.authorize.net/authkb/index?page=content&id=A1759

The big takeaway about when it runs is that there is one combined monthly batch for all merchants. The batch starts at 00:00 UTC on the 14th of the month, and the total time to run depends on the number of merchants and the number of updates. Updates to your profiles should be available for use as soon as that particular profile is updated. However, your report of the cards updated is not available until the following month.

What I'm still trying to find out:

If the batch finishes sooner, will the reports be available sooner, or is it not until the following month, no matter what?
Will the reporting API give you results as soon as the profiles are updated, or is that also not until the following month.

kris-btp · ‎08-21-2017

Aaron, what I do not see on that KB is how to test this functionality?

Will we be provided a method to trigger an update in our developer environments to have positive control over details?

Edited for clarity.

Aaron · ‎08-22-2017

Hi @kris-btp,

There's no way to trigger an update, even in sandbox. What I do have for you, though, is a list of credit card numbers that Account Updater will do something about in sandbox. Using this list, you can at least test a variety of scenarios when the process actually does run.

We'll update our online testing guide with this list soon, but in the meantime, here's the card numbers:

Card Number	Expected Result
4000001864810239	NAN
4000007113112087	NED
4000002055487183	ACL
4000003586276236	CCH
5111111015486814	NAN
5111111069713154	NED
5111111018673020	ACL
5111111073508855	CCH

kris-btp · ‎08-23-2017

Aaron,

This is fantastic and exactly the information that I needed.

mikecimi · ‎08-29-2017

Does account updater work on all processors? I'm mainly concered about TSYS and First Data but if it's not all, is there a list somewhere?

Thanks

Aaron · ‎08-29-2017

Hi @mikecimi,

It's processor independent. The actual process of retrieving new card numbers runs directly through services provided by Visa and MasterCard independent of whatever processor connection you have for your account.

Cybersource Developer Community Cybersource Developer Community

Re: Account Updater

Photos