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.
I am sending a createTransactionRequest with <createProfile>true</createProfile>.
If there is already a profile associated with the credit card the following error is included in the response:
<text>A duplicate record with ID 1812052420 already exists.</text>
Then I have to send a getCustomerProfileRequest to get the customerPaymentProfileId which is required in order to use the profile in the future.
Is it possible to include the default customerPaymentProfileId in the error message so I would not have to send another request to your server?
In our system we want to use tokenization but we can't always precreate the profiles.
Lynn Millard, Software Engineer
The Hudson Group
360 Merrimack Street
Lawrence, MA 01843
It seems like almost a no-brainer to have a method, using Accept.js, to get a payment profile, so that a self-hosted payment form could be populated without from the client machine, rather than having to go through our server using the API. It seems like all it would need is the customerProfileID and the customerPaymentProfileID to pull that info, just like the existing getCustomerPaymentProfile() method found in the AuthorizeNetCIM class.
A credit card payment can only be refunded for up to 120 days without having to resort to using ECC. ECC is cumbersome and creates PCI compliance hassles. Competitor gateways can often refund transactions up to a year after they happen.
Please extend the non-ECC refund window to 365 days.
We would like to be able to bill our clients in one currency, and have the funds settled into our account in another.
As an example, we would like to charge our UK clients in GBP, and then have the funds converted, and deposited into our Australian bank account in AUD. I think it's important that our clients always know exactly how much will be deducted from their credit cards, as opposed to having it fluctuate each month based on that days exchange rate.
I contacted Authorize.net to see if they offer this service, and they suggested that I post the suggestion here. If this option was available, we would be happy to have multiple Authorize.net accounts - one for each country/currency that we have clients
I'm currently working on a solution where our customers have requested a migration-tool, to tie existing CIM entries to their business partners in their ERP system.
In this case a method to retrieve all CIM profiles along with their corresponding payment profiles would be helpful.
Currently the only option is to query the API for all CIM profile IDs and then iterate them and call the API for each one.
In the sandbox environment this takes roughly 20 minutes for 4000 entries, using multi-threaded requesting. This performance is obviously pretty poor, and I imagine the method I described above would allviate this problem.
There are many solutions providers that are trying to integrate with a payment processors to give their clients a robust system - not only for people paying them, but for paying their employees as well - via direct Deposit. For example non profits (and many for profits) need to accept money via online (donations or payments for products and services). Authorize.net has this portion down - Hooray!!! The part we need in a full CRM - Enterprise system is the ability to make payroll direct deposits to our employees. Churches and other companies use software like what we offer to keep all their systems running but we need a processor in the back end that can handle any type of money movement ie - one bank to many banks (direct deposit), receiving money from multiple banks to one bank (paying for something online from multiple clients), making payments to vendors, and so on.
Thanks for listening.
Many stores need an automatic return to register the conversion for Google eCommerce. By limiting the SIM method to a manual click by the customer causes a high degree of abandonment at the payment completion stage and therefore, no conversion registered with Google eCommerce. It does work as it should if authorize.net's domain is excluded in the Google eCommerce settings AND the customer clicks on the authorize.net receipt page button. HOWEVER, many times, they don't.
This is aggravated by the fact that the receipt page proclaims "Thank you for your order!" in bold text that is hard-coded and cannot be changed by the merchant. This reinforces the impression to the customer that he is done and exacerbates the abandonment issue.
The Relay Response method DOES NOT WORK correctly when using SIM, and Silent Post URL does not send the information needed to clear the customer's cart in the store.
DPM is out of the question due to issues regarding that approach not actually lessening scope of PCI compliance. Officers at companies like Trustwave state that it puts the store completely in-scope and is no different than AIM, regardless of claims that by Authorize.net that DPM lessens scope.
There are 2 things that need to be addressed and modified in the SIM receipt page:
1. There should be an option for the post back to the merchant store using SIM be automatic and not wait for user input on a receipt page. (Again Relay Response does NOT work!)
2. The field that states success on the receipt page ("Thank you for your order!") should be editable text by the merchant for situations where the receipt page IS displayed but a different message is desired.
Please consider these two minor modifications to the SIM platform. They would be a great benefit to many, many merchants, especially those using conversion tracking systems.
One of the problems with using CIM hosted forms is that it's difficult to determine what profile information has changed (payment profiles added or edited).
Another issue is that it's difficult to provide an audit trail which identifies who initiated the changes.
One possibility that could address these issues is specifying some kind of reference id (not the per-transaction refid field) in the getHostedProfilePageRequest which would be assigned to each payment profile (or shipping address, although this is not something I use) which the end user created or edited using this token. Or it could be the token itself.
Then return that identifier for each payment profile (or shipping address) returned by
End-developers can easily identify which payment profiles were modified by a specific token consumer. We can also provide an audit trail of which token consumer modified a record most recently.Comments?
Currently, there is no method via the API to validate and reconcile ACH payments from echeck transactions made to our bank account. Payments received into our bank account do not contain any tracking numbers or relation to which batch(s) are included in the payment. Therefore, we cannot finilize the confirmation of payment per person based on teh ACH deposit. According to Authorize.net support, the only way to determine which batches are included in a given payment is to manually review the Funding Calculation immediately prior to the ACH transaction. We find this cumbersome and unrealistic in a production environment. Instead, we propose additions to the API.
Without at lease 1 & 2 above, there is no API (a.k.a. automated) method to validate receipt of funds per batch and transaction which leaves the merchant exposed to missing failed deposits or other ACH issues.
Abiility to fetch the list of required field names in the payment form via API
With the complexities of SAQ A, EF, D and the opportunities of globalization (i.e. en-CA, fr-CA, en-US, es-US, es-MX; North America + Mexico) it would be great to have localizable capabilities offered in your HostedForm and DirectPostMethod implementations.
My thought is to add hidden text fields i.e.;
For fields like;
- input type="hidden" name="x_invoice_num" value="dpm3-inv3-123"
Add a new tag like;
- input type="hidden" name="x_invoice_num_label" value="Invoice Number:" .
This would go a long way to improving/solving localization and keeping PCI DSS to a minimum for the companies building solution with AuthorizeNet's SDK.
Right now, connection details logged from HttpUtility at the debug level include a great deal of useful information along with
- the api login and transaction key
- full dump of the xml request including unmasked credit card number, expiration date, etc.
Can we move the logging of these two items to a separately-configurable logger like "HttpUtility-sensitive"?
I'd like to see the api login and transaction key logging go away completely from the HttpUtility output.
ideally, I'd like to see the xml request filtered to not show any <payment> information beyond a generic <creditCard> output. (I suppose masked credit card number would be acceptable).
I think it would also be wise to not output <billTo> information nor <customer> information with the non-sensitive-data logger other than <customer><id> even though this is not strictly required by PCI DSS.
We want to log when transactions occur with enough context to know what those transactions are without making our logs a security risk.
Currently there isn’t a way to create or retrieve a customer’s profile using a GUID. It would be beneficial to use a GUID in a customer’s profile when created and retrieving the customer’s profile information. The current API requires the customerProfileId to be known in order to get the customer’s information. Using a GUID to get a customer’s profile information will allow easier linking from a company’s database to the payment gateway without having to know the customerProfileId.
Add a feature, that will allow to retrive an amount of transaction, that was not refunded yet.
I.e. original order with 5 items was made for 50$ and transaction was authorized and captured.
Customer returned 1 item and refunded 10$.
Need an API method, that will allow to retrive the amount, that can be refunded.
Right now there are 2 ways to solve this case:
1) POS side tracking. This methods requires huge amount of analytics on server side and may cause the data to be incorrect if system has multiple clients, that has their own storages.
2) Cashier tries different amounts to guess which one is available.
I have been reading about you guys not implementing pin numbers to allow customers to enter a pin number prior to transacting a sale. I find that makes no absolute sense by no means whatsoever. Why would you NOT allow pin numbers and only have credit card only transactions?
Please, as a U.S. standard for the majority of the states allow pin numbers to be entered so card holders can feel safe that they can enter a pin number. That should be something standard with any card swiping capabilities.
I need to be able to create new payment profiles on existing customer profiles at the same time as a transaction is being done, so I can skip the test transaction step. Currently, I can create new payment profiles with an authCaptureTransaction only if I also want a new customer profile. I am getting lots of complaints about the test transactions, and this would solve the problem.
There needs to be a way to verify if a transaction has already been posted or not in order to help eliminate possible payment duplication. This could work by searching for an invoice number, date, and possibly even a payment amount; and get a list of all transactions where there is a match. This way I can make sure my application isnt trying to charge a second time when it should not.
Our store uses WooCommerce (WordPress) and we use Google Analytics to track our transactions. Because users leave our site to make their payment via Authorize.net, Google Analytics is unable to correctly attribute the subsequent conversions (showing as referrals from authorize.net).
We've setup Analytics in Tag Manager and have enabled third party cookies (auto link domains), but without actually adding the code to the authorize.net pages, this is useless. I've seen many places where your customers ask this exact question and yet I've not seen a single workable response. Please create a way customers (or their developers) can enable and implement this tracking continuity.