Cybersource Developer Community Cybersource Developer Community

The integration forum is getting inundated with spam and bots. Can we have a “mark as spam” button to get rid of them? Ideally the agents IP address could be blocked once marked as spam. ... View more

There should be a way to retrieve transaction details by their invoice number. If there is a network failure the only identifying information we have is the invoice number (not the Authorize.net generated transaction id).   Using the getUnsettledTransactionListRequest call is a bad choose since it only returns the last 1000 records. ... View more

As mentioned in the following post:   http://community.developer.authorize.net/t5/Integration-and-Testing/Masked-Expiration-Date-in-Hosted-CIM-s-getCustomerProfileRequest/m-p/32333/highlight/true#M16895   The card expiry date is masked when returned in the getCustomerProfileRequest.  As the card number is masked, there is no PCI requirement that the expiry date of the card also be masked.  Without the expiry date, it makes it impossible for us to automate the process of notifying our customer's clients that their card will be soon expiring.  The reason for us going this route is to offer an ARB solution managed completely from within our application.  It is imparative for us to have access to this date.   The idea is a simple one.  Return the expiry date in the CIM getCustomerProfileRequest unmasked.   Thanks. ... View more

Hi, I have reviewed all documentation and it is apparent that there is no way to style the form in the Accept JS Hosted form.  In order to do so, we would needto create our own form and submit it via JS.  Thus, opening us up to SAQ A-EP requirements; which requires a lot more time investment to manage.   I also understand that SAQ A requires any vendor (Authorize)offering CSS manipulation to verify all code submittedfor security. There should be a way to do this programmatically, where only a subset of CSS would be processed, and the rest eaither ignored or appropriate errors raised.   Not allowing styling makes for a confusing experience for the end user.  They have spent a long period of time on our site choosing items to buy, only to end up on a page that looks nothing like what they were just on. Even if it appears in a pop up, it is still a little unsettling to the user that they will be putting card data into something that looks so different.   It would be greatly appreciated if a method be could created to allow for the styling of the form.   Has or is this being considered?   I have seen a few other comments with regards to this, but there is no other detail than to create your own form.  There are other vendors offering this fetaure.   I would hope/expectthat Authorize.  Net would offer it too.   I look forward to your response.   Thanks! ... View more

Currently, there is no easy way to get a list of transactions for a given subscription id.  To get a list of transactions for a subscription id. I load the subscription to get the customerProfileId and payentProfileId, call getTransactionListForCustomerRequest(customerProfileId, paymentProfileId), loop over the transactions returned in the response, and evaluate if transaction.subscription.id is equal to the subsciptionId I am looking for.  Furthermore, getTransactionListForCustomerRequest() uses paging, so I may need to call that API multiple times to get the collection of transactions for a subscription.   I am requesting there be a new API to get a list of transactions for a subscription id.  The new method would implement the standard paging and sorting.   See this Community Forum Discussion   Thank you for your consideration.   ... View more

Proposing that the webhook events functionality be expanded to include eCheck returns, chargebacks, and refunds. Currently these transaction types do not generate any webhook events and thus require calls back to Authorize API. ... View more

When creating a customer profile and receiving the E000039 error that tells us there is a duplicate customer profile that already exists it would be useful to get that duplicate profile ID in the response other than inside the error text. While technically possible to pull it out of the error message it would be much easier and less prone to issue if we could get it back somewhere directly, such as the CustomerProfileID filed that already exists on the createCustomerProfileResponse object.  ... View more

Recently we had an issue where a merchant (we act as a service provider) had already refunded a transaction via the merchant portal then when attempting to refund it through our service we encountered error code 55. We had no other way to determine if the transaction was refunded/settled other than walking our way back through settled batches closed after the initial capture's date (or calling A.net support). So, my proposal is this: add an array of refund transaction IDs (complete/partial) to the `getTransactionDetailsRequest` response ... View more

When a webhook notification is recieved there is no way to trace it back to a customer/event/action.   In the case of hosted forms (i.e. Accept Hosted), none of the values (e.g. invoice number) submitted in the request for a form validation token appear in the webhook notification, so there is no way to immediately know what the webhook notification is in regards to.   This forces us to always query authorize.net for the transaction details to see what the transaction applies to (e.g. invoice number) and confirm the transaction is completed.   I imagine that a webhook notification alone is not especially useful unless it provides access to a correlation token and status. Because these values are small in size and almost definitely required by any merchant software, I feel the very small increase in payload could greatly reduce the need for subsequent queries - saving merchants as well as Authorize.net a lot of extra processing and network traffic. ... View more

Hello all,   We operate as a service provider, rather than a single merchant. A lot of our merchants are not too tech savvy so asking them to generate a public key (we're switching almost all merchants to Accept.JS from AIM) is like pulling teeth most of the time. Maybe when a merchant signs up a public client key is automatically generated for them or there could be an API request that generates a key for them so we can obtain the key from a 'getMerchantDetailsRequest'.   Also once again: love your service, your API is much better documented than a lot of your competitors, it's much more robust and the Accept.js library is easy to handle.   Myles ... View more

The ability to set the soft descriptors for a transaction.    These are the fields that a customer sees on their statements, it allows for the customer to quickly ID the transactions reducing disputes and customer service.  For obvious reasons I hope.   Dynamic Descriptors include: Business Name Phone (Best Practices says this should be a Customer service number) City and/or State ... View more

Accept.Js works great!  It allows my website to capture Credit Card information without that data ever posting back to my servers.  I don't any PCI Compliance headaches.   My suggestion would be to enhance Accept.JS to also allow for ACH payments.  That is, have accept.JS allow for the capture of a Routing and Account Number.  It could look like this:   var secureData = {}, authData = {}, bankData = {}; bankData.routingNumber = document.getElementById('ROUTINGNUMBER_ID').value; bankData.accountNumber = document.getElementById('ACCOUNTNUMBER_ID').value; secureData.bankData = bankData; authData.clientKey = '6WrfHGS76gHW3v7btBCE3HuuBukej96Ztfn5R32G5ep42vne7MCWZtAucY'; authData.apiLoginID = 'my_api_login_id'; secureData.authData = authData; Accept.dispatchData(secureData, 'responseHandler'); Here's a related communit post.   https://community.developer.authorize.net/t5/Integration-and-Testing/Accept-JS-and-ACH/m-p/55887#M30714   Thank you for your consideration! ... View more

It would be great if there was a test token that could be used to test the server side code that transmits the AcceptJs token to the Gateway, similiar to the way one uses test credit card numbers. ... View more

Please add a webhook for failed transactions, no matter the reason (expired, processing error, general error, whatever).   I'm not sure what kind of company wouldn't want to know immediately and automatically about a failed transaction, especially if it's for a subscription (ARB).   Silent Post does this and we're trying to migrate away from it per customer support advice but glaring omissions like this are making it near impossible.   The only solution is to either constantly query the API for unsettled txns to find failures (if we want to know about them immediately, which we do), or if we didn't mind waiting up to 24 hours then we could query once per day for the entire batch for the previous day to get all transactions and find the failed ones - but this is 2018 damnit, everything should be real time. ... View more

When submitting a capture of a prior auth request, allow an update to the invoice number field.   We do not generate an order number until the authorization is captured, and therefore cannot add the proper value to this field on authorization. The API does allow me to include a new Invoice number on the capture request, but it doesn't actually update. ... View more

For those of you who aren't aware, Authorize.net has cancelled the Expanded Credit Capability/"ECC" program that allowed for unlinked refunds. This was the only way to issue a refund after 120 days, since Authorize.net does not retain cardholder information for the original transaction past that.   ECC is a very old program and it frankly sounds like a terrible idea, particularly with security standards today. It has no requirement that the refund has anything to do with the original transaction, so there is an obvious problem with anybody who has access to merchant credentials having a lot of opportunity to misbehave.   Our use case is pretty different and I believe that there is a lot of possibility here for Authorize.net and its customers without any additional exposure to risk, and that is the use of the Customer Proiles feature to enable the option for refunds after 120 days.   In an ordinary, non-profile transaction, Authorize.net has got to save the customer credit card number for every transaction. They don't want to do this a second longer than they have to, which is why the 120 day limit is there. OK, no problem. But with a customer profile transaction, they don't have to save anything that they don't already have: the customer provided their card info in a secure manner and Authorize.net will hang on to it until the customer deletes it.    The API already accepts the use of payment profile IDs to issue refunds. So why not carve out an exception that allows merchants using customer profiles to issue refunds for any period of time, so long as the payment profile is still active? If the customer deletes the profile, you wouldn't be able to do this; but if they don't, the argument that "we don't have the card info to issue a refund" just isn't true. There's not a lot of potential for abuse because the transaction is still a linked refund; you're not holding on to anything you weren't already going to hold on to; and you have none of the security problems of unlinked refunds.   We talked to your service department about this and the suggestion was 'escalated' but not taken seriously. They thought we were asking for something just for our account. We're not. We're asking for something for everybody's account, because the current configuration of refund options is based on assumptions from ten years ago and the use of ECC to resolve the problem. Both of those things should get a fresh look with all of the new tools that Authorize.net has added since then. We are happy to assist with this process as our customers (who are sports leagues for which people sign up 8-12 months in advance) are pretty grumpy about having to write hundreds of checks when refund time comes. ... View more

Despite using best security practices to protect passwords, we consider the single form authentication to the Authorize.net portal to be a critical security concern.   The concern is especially high with regard to CIM. When CIM is enabled, anybody breaking into the Authorize.net account can do a lot of damage (like creating transactions).   We are in 2015 and two form factor authentication is widespread and easy to implement. It does not have to be a full blown 2-factor with MFA devices. A simple solution - for example using a mobile phone access code - would already be a huge improvement over the current system.     ... View more

Smarther a leading ecommerce app development company providing more quality app development services from the hands of passionate and experienced ecommerce app developers. ... View more

Hello,   The issue is that Authorize.Net is not providing a « Company Name » field on the payment form for « Accept Hosted ». Also, sending this info through the API under the “billTo > company” tags has no effect on transaction details on Authorize.Net (the Company name is not shown on the invoice). This is a blocking issue for my customer (and yours). Could you please be able to provide any relevant details regarding the following issue? Thank you in advance for your prompt response. Regards, Benjamin C. ... View more