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 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!
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
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:
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.
I have implemented accept hosted form into iFrame and embeded that iFrame into my main payment page.
Now my payment page has a cancel and previous button itself. so, after integration of accept hosted form there are two cancel button in my page.
We are looking for such a feature by which we can show/hide cancel button in accept hosted payment page.
The identifying information that's included in Silent Posts (x_cust_id, x_subscription_id, etc) should always be in webhook transactions, if not just everything in Silent Posts. I know about refId but that's of no use to companies using ARB for recurring billing, which is 99% of our transactions.
This is making my migration to Webhooks difficult. Your support staff has obviously been instructed to push everyone to webhooks if they're using Silent Post right now but the glaring omissions of functionality in webhooks is just absurd.
The only solution is to query the Authnet API for information on the transaction ("getTransactionDetailsRequest"). The response that comes back from that query is very detailed. That detailed response should just be webhook. Why the heck not? Come on now.
It would be convenient if Authorize.net would create and support an npm package that contained the production and sandbox versions of Accept.js.
I am implementing a solution in Angular and currently have copied and pasted the file contents and put them in my application.
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.
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.
Recently I started implementing ARB on application (using php-sdk) and the implementation went smoothly until I hit a road block. I was not able to pull transactions for a subscription. In fact what, I would really prefer is to use the merchantCustomerId to pull all the transactions for that customer. Both, getting transactions for a subscription or getting transactions for merchantCustomerId, is all implemented on the merchant interface, but we are not able to use it through the API. So i know the integration between ARB and CIM is there, just not exposed to us developers.
Whether Authorized.net patch MD5 to SHA512 provide support or a separate patch for PHP 5.6 version website to avoid payment failure without any error.
Moreover, the same Patch will work for PHP 7.0.1 version website.
I was advised to submit an idea here.
When printing a receipt in Google Chrome, clicking on "Print using system dialog" closes the window. This happens in production as well as the sandbox.
Account Updater deletes Payment Profiles stored in CIM due to the fact that they are marked as "closed" by the issuing bank. However, some customers continue to re-enter the same card details month after month showing that this is fact a false positive.
When attempting to process a payment against these cards, they are succesful, and don't return a closed status. There is a flaw in the data passed by the banks to account updater, or in updater itself.
In my limited testing, I discovered this was happening to several % of my cards every single month costing me thousands in revenu in a pretty short amount of time.
Several other Authorize.net users have noticed the same problem
My guess is that if everyone who used CIM and account updater looked at their monthly updater report, and checked the last 4 of cards deleted, they would find that it's deleting some of the same customers credit cards every single month!
The account updater sales page states that, "It costs 7 times more to get a new customer than to keep a current one." yet account updater is deleting active card data every single month.
Three potential solutions:
Since I've been told by customer support that this can't be fixed, I would like to point out that Stripe does not have this same problem with their account updater, and in my testing, my card churn rate was much lower with Stripe.
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.
When a customer does not enter the correct credit card details, there is a warning sign added next to the credit card as well as the field's underline becomes red. This is fine but when customers are on smaller displays, they need to know to scroll back up the form to find the error.
The suggestion here is to add an error message just above the "Pay" and "Cancel" buttons (just like some of the system errors like the "declined" messages) which describes to the customer what the problem is so they know to scroll back up to fix the issue.
We are seeing significant problems with our customers and they wind up canceling the transaction!