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.
In createTransactionRequest we are able to create a new customer profile from data which was sent in this API call by setting <createProfile>true</createProfile> flag:
<profile> <createProfile>true</createProfile> </profile>
Since customer is only being created after transaction is set, and not assosiated with it, any of GetTransactionList, GetUnsettledTransactionList and GetTransactionDetails API calls will respond with empty customer profile field.
Flag <createProfile> only declares that profile will be created, so this is an expected behavior. But also it might be usefull to associate customer profile with transaction where it was created. A new flag might be added to avoid changing <createProfile> strict behavior, and at the same time add more flexibility to this call:
<profile> <createProfile>true</createProfile> <associateWithTransaction>true</associateWithTransaction> </profile>
, or something similar.
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.
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.
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.