Cybersource Developer Community Cybersource Developer Community

A way to email a simple checkout link would be great.  I give custom quotes and it is very difficult to create a simple checkout button, then create a new page on my website then email the link to my customer, have the customer browse to my website, click the checkout  button and enter their information.    It would be much easier if I could email them the simple checkout link, then have them click the link from directly in their email and checkout. ... View more

Currently, to avoid most PCI compliance, the hosted CIM is the suggested solution.  The problem with this solution is that it is very clunky and does not integrate well with any custom interface.  It uses an Iframe solution in which you have no control over the appearance of the form fields.   Stripe offers a javascript solution which basically does the same thing as the hosted CIM but allows for the developer to seamlessly integrate the form folds into an existing system.  I was curious of Authorize.net is planning on any sort of similar solution down the road.   Thanks! ... 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

Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/How-to-set-billing-info-in-CIM-hostedForm/m-p/54627   Add ability to pre-load billing information into CIM hosted form.   Our customer's billing information is already stored in our system, and we do not want to force them to enter it a second time when adding a payment profile.  We would prefer instead to show the current billing information as the default values and allow them to modify the displayed information if the billing infomration is different for the credit card than what is already on file.   ================================   carlosdanielmou wrote:   In our system the user complete billing information, and when we show the form of the CIM hosted API, we need such data are loaded in the form, as we do that?   First we call to createCustomerProfileRequest,  with merchantCustomerId and email.   Then I call createCustomerShippingAddressRequest with customer billing address   and then, I call getHostedProfilePageRequest. ... View more

With Accept Hosted, when a successful transaction is done, a message displays that says, "Thank-you for your business!" This message should be editable, as it assumes a particular type of transaction just took place, when it could be many things.   Thanks, Mark ... View more

Idea: A read-only key that can be generated specifically for the Transaction Details API.   Background: We are developing an app that only uses the Transaction Details API. Which means we are only reading information.   From a liability standpoint, we want to avoid saving a write-capable transaction key.   Ideally a separate "read-only" transaction key could be created when a user turns on the Transaction Details API. ... View more

Does Authorize net have plans to integrate with Zapier? It is has been listed on their website as "upcoming" for over a year. When will it come?  ... View more

A customer on my site just attempted to place an order with a valid Discover card number that is 19 digits long. Apparently, Discover and Visa have begun rolling out valid cards with 19 digits. The card passed my Luhn algorithm validation and was passed to Authorize.NET for authorization. The XML request was sent succefully; however, I received the following error response from Authorize.NET:   The 'AnetApi/xml/v1/schema/AnetApiSchema.xsd:cardNumber' element is invalid - The value XXXXXXXXXXXXXXXXXXXXX is invalid according to its datatype 'String' - The actual length is greater than the MaxLength value. I checked on the Authorize.NET documentation, and it appears that only card numbers between 13 and 16 characters long are supported. When will this be changed to accommodate 19 digit card numbers? ... View more

Just posting here in case someone finds my post before wasting further time on this issue.   I have an app that uses authnet's API to take payments.  I also use their fraud detection suite, specifically for many of the IP address-related filters (velocity, shipping mismatch, regional blocking, etc).  I'd been conducting business like normal for some time, no issues.  I recently had my web host enable IPv6 for my site to get the benefits it providers for mobile shoppers who often see faster performance over v6 due to not having to go through carrier NAT for IPv4 in high density areas.  Everything seemed like it was working fine initially, but then I heard from a customer who could not pay.   After some debugging, we found that my payment code was populating the authorize.net API field customerIP / x_customer_ip with the customer's IP, which is obviously what it is intended for.  I was populating it with both IPv4 and IPv6 addresses.  The field is only usable for IPv4 ;if you pass IPv6, it will decline the transaction.   What's worse, is that since I have fraud suite features enabled, I have to pass an IP.  So what to do for an IPv6 shopper?  I can't pass a placeholder IPv4 address, such as always passing my site's own IP when the shopper is IPv6, because I'd end up triggering the velocity filter.  So ended up having to go back to not having my site IPv6 enabled.   I found someone asking about IPv6 and that field as far back as 2011, and authnet still hasn't caught on.  Comcast is IPv6-enabled nationwide, as is nearly every 4g cell network, so this isn't just a fringe customerbase I'm wanting to support.   ... View more

There needs to be a feature that allows you to get subscription information like when was the last valid payment, all attempt of card processing and whether it failed or went through, etc etc etc. ARB really is tiny with no usefull functions other than create and cancel subscriptions. Even the update is useless with the amount of things u can update about a transaction. So please add some features that gives users some idea of what is going on with their subscription. Is there a better payment processor than authorize.net that does this? ... View more

Hi, An option of a payment page would be a great idea! For a retail business which uses a gateway due to the convenience of reporting etc., it is very annoying to need to login each time a customer wants to pay. If a merchant processes payments every 10-15 minutes, although they still have authorize.net open the page logs out due to inactivinty and they need to login again. This means they constantly need to login in. ANNOYING! As well, authorize.net does currently not properly support level II & level III processing. (Although you claim you do) Numerous merchants entered the data in the fields you advised and did not qualify for level II -level III rates. When they processed with a different gateway, they did. (IT"S A BIG PROBLEM!) The authorize.net community would appreicate action to the above mentiones matters. Thanks! ... View more

Would like to be able to customize the pop up for managing payment profiles. It would be great if the Payment Form Fields configuration checkboxes applied to this, so that for example we could turn off the shipping address. A seperate place to configure this would also be fine. ... View more

Please allow us to fully customize the email receipts. You finally allowed us to change the description of the normal recipt. Now expand that to allow customization for recipts from transactions flagged by the fraud filter.   In 2015 I can't even comprehend this restriction of not letting the customer dictate what the recipt should say.  ... View more

The current minimum 7 day interval for ARB makes testing impossible. Developers need a shorter interval, for example 1 minute, to be able to test their applications. ... View more

Hi   Following our recent Gap Analysis for PCIDSS Compliance, it was suggested that at the point of entering the Credit/Debit card details for payments, the PAN should be masked. This would then take away the opportunity for screen scraping where the user could screen shot the full details, or copy and paste them somewhere else.   After getting in touch with the dev team at Authorize, they have advised that this would be a good idea to get rolling and the best way to do this is to add it here. So here we are!   Many thanks Amber ... View more

It would be very helpful if the Accept Hosted payment form iFrame Communicator could send a communication indicating when the payment form is fully loaded in the iFrame.   We are seeing issues in some browsers (especially Safari) where scrolling while the form is still loading (before the iFrame has been resized) can result in portions of the form being hidden and no scroll bars to bring it back.   If we had notification of the form being fully loaded, we could block pointer events and scrolling for the iframe until after the the page is fully loaded. ... View more

Hello Authorize.net Community. We have recently implemented the new Accept hosted mobile optimized forms and we wanted to know if anyone has any success in hiding some of the following fields: - City - State - Country - Phone   Unfortuantely that function the option to show or not show the billing address options and that is by setting the property for hostedPaymentBillingAddressOptions https://developer.authorize.net/api/reference/features/accept_hosted.html#Requesting_a_Token allows us to disable all of the billing fields and our challenge is that we only want to enable the address fields that are required (i.e. Street Address, Zip & Phone). Based on our research and your responses from your forum, it looks like this is not possible. Hopefully your teams can consider these non-required fields as definable options separately in the future.   Thank you in advance for your consideration.   Best regards, TS ... View more

The CIM iframe works great but lacks some display options.  For example, I use it at a newspaper where the billing and shipping info are both useful to have.  Unfortunately we cannot change the name of "Shipping" to delivery.  In the case of a newspaper, this might imply we will mail the subscription which is not the case.  It would also be nice to be able show or hide the shipping field if it wasn't needed.   The iframe should also support a responsively designed site.  It will position further down on the page by default when viewed on a mobile device. ... View more

As noted in the FAQ, Authorize.net waits 10 seconds to receive a response from DPM POST requests: http://developer.authorize.net/faqs/#rrcauses   It also notes that "On occasion, timeouts will occur that are outside of the control of your script or our servers. Typical reasons for these timeouts are Internet traffic, merchant server overload or malfunctions, or Internet routing issues. Depending upon your server location and what route is used to send data, it is possible that you may occasionally receive a time out message."   It appears that Authorize.net does not retry a failed POST, even if the 10 second timeout has not been reached. This was confirmed by an admin in the forums ("We currently do not retry failed posts").   I propose that this behavior be changed. If an Authorize.net POST request fails, prior to the 10 second cut-off, the POST should be retried, possibly with a short backoff (e.g., wait a second or two to reinitiate, to prevent a flood of requests).   As background, we have been using DPM successfully for a couple of years now, but we do occassionally see "timeout" errors. Crucially, it does not appear that these are actually caused by timeouts. The first thing we do in handling the response is log receipt of the request. But we see no evidence of having received the requests in our logs. Which suggests that the problem is happening outside of our network.   As it currently stands, Authorize.net's POST request could fail immediately due to some extremely transitory issue (perhaps even within their network). They would immediately receive a "connection reset by peer" error or whatever. And even though virtually none of the 10 second timeout period has been consumed, the customer receives a timeout error.   The DPM process should make more of an effort to communicate the transaction status and prevent this failure scenario.   Possibly related to this request would be additional logging facilities, so that both Authorize.net and its customers could have more insight into what exactly is occuring. IOW, it would be very helpful to have some visibility into *why* Authorize.net's POST request failed, and how long it took. It could provide much needed stats to discover how often the "timeout" problem is happening and whether these suggested changes are actually making a difference.             ... View more