A place for community members to contribute product ideas and suggestions.
A place for community members to contribute product ideas and suggestions.
Have your own great idea for a new API feature?
or maybe a suggested improvement to an existing one? Share it and become a god of the developer world.
Since when you call the getCustomerProfileRequest and it will list all the payment profiles can you please add a field as to which one is the default one?
This would be extremely useful when showing a user a list of all their profiles and which one they have set as default. Otherwise it takes a lot more unecessary coding to show all the payment profiles and then have to determine which one is the default by making additional API calls.
Currently, transactions flagged as suspicious and held for review by the Fraud Detection Suite can only be approved via the Merchant Interface.
It would be much more convenient if we were able to approve these held transactions via the API without requiring our admins to log into the Merchant Interface.
I have just recently wrapped up an integration with Auth.net to our website and erp system using CIM and the Payment Transaction API. Our system is passing the Level 3 data to Auth.net, but Auth.net doesn't pass this information to the processor. I was curious about the decision for Auth to hold onto the data and not deliver it to the processors and if this feature is on the roadmap? I would love to have the L3 data passed around, we could realize an incredible amount of savings from this (fees can be cut by up to half with this information, That's huge!).
If this isn't on the roadmap, please consider adding support for this.
Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/How-to-set-billing-info-in-CIM-...
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.
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.
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!
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.
Idea: A read-only key that can be generated specifically for the Transaction Details API.
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.
I have a scenario where I'm performing an authorization with a payment nonce, then creating a profile from that successful authorization, and later capturing the authorized amount. This is a nice workflow because I only create a payment profile if the authorization succeeds.
But unfortunately, this workflow is not possible because the authorization is not associated with the payment profile, and doesn't show up under its history. In a scenario where we're using a profile for recurring transactions, it's a big deal to us to have the initial payment in the history.
See this thread for more details as to alternatives that are less ideal.
It'd be very helpful if, when I create a profile from a transaction, if that transaction became the initial transaction in the payment profile's history, and I was able to capture it as though it had been issued from that profile.
Hi there, we absolutely LOVE the new online invoicing feature - its super simple and most importantly, it makes running our business easier!
Are there plans to add a "recurring" feature - the ability to automatically send the same invoice, to the same person, on a monthly basis? We have a category of payments that we collect on a monthly basis that having a recurring invoicing feature as part of the new invoicing tool would eliminate the manual re-entry every month.
For the developers if they want to control over showing pay, cancel option, they cannot currently.
When the pay option is clicked, customers are selecting cancel option. But, the form is not cancelling the transaction to proceed. But, customers are not unaware and they are submitting another transaction. More details here.
Can we have the following so that developers can have the option to hide in the form? this helps the merchant customers not to cancel after they click pay.
once the pay button is clicked, disable the cancel button so that end-user doesnt have an option to select cancel.
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?
As we build out our integration we noticed it would nice to have some additonal search types added to the getCustomerPaymentProfileListRequest endpoint. The most useful for us would be to search by customerProfileID. Also an expiration date range would be nice along with a paymentType (credit card or bank account)
A future request i could see is having the ability to have multiple searchTypes like customerProfileID and and an expiration month/year or range, or customerProfileID and paymentType.
Created from previous thread: https://community.developer.authorize.net/t5/Integration-and-Testing/refundTransaction-requires-expi...
Currently, to refund a transaction, you must provide both the masked credit card number and expiration date. Yet this information adds nothing to the request -- in fact, if you no longer have this information, you must issue a separate getTransactionDetail transaction to fetch this information. Rather than requiring two separate transactions to perform a single task, only require the original transaction id.
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.
We get notifications for a normal subscription transaction, but what of the trial transaction?
Isn't it weird that we have no notifications for this? like it is a ghost transaction. But it exists and we should be notified about it.
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.