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.
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.
One of the items we used frequently in the AIM integration was the “x_test_request” toggle for the production server. We're updating our integration for the new API and unfortunately, I am not seeing that option. In the forums as well as through the Sandbox support, I've just been told to use an “authenticateTestRequest", which simply does an "authenticate credentials". However, this is insufficient for onboarding and provisioning of new clients and I would like to see an actual "test mode" flag brought forward to the new API.
The use of this flag to change into test mode on the production server does several things for us:
1. It allows us to do full end-to-end testing of our setup (outside of the actual API integration). While we can use sandbox credentials for this, this becomes a QA issue for setup/provisioning. Using this flag allows us to set up everything exactly as needed and then simply flip a switch to "go live" on our end, as a service provider.
2. Having the ability to use live server credentials in test mode for our customers is important for those who are transitioning their service to us and may not be able to set their whole account into test mode. There are other customers with which we may just not be able to control the test mode status of their account for various reasons, so having this control at the API level (for individual transactions) is very important.
3. It is important even in test mode to be able to get the same “accept/decline” responses as we formerly could in AIM, and not just do “authenticate credentials”. How a given merchant may use the transaction data with us will vary based on their application and we need to be able to do full QA testing.
By the way, even if it did what we needed, I do not see an option in your API to just do an “authenticateTestRequest”. There is no code sample in that section of the API reference, so I’m guessing it’s not included as a formal part of the API?
Would it please be possible to support EMV transactions without UI components in a background service on Android devices?
It would make it so much easier to integrate EMV transactions in solutions that already support AIM transactions and provide e.g. signature capture, if simply the required information (authentication credentials, amount, invoice #) had to be provided to that background service which would just return the result of the transaction.
Thanks for considering!
Currently only 3 tablets are supported by the In-Person SDK for Android:
1. and 2. seem not to be in production any more, and 3. is fairly expensive.
The Samsung Galaxy Tab A 10.1 seems to provide very good value for its price but is not completely supported by the In-Person SDK for Android. When using the currently only supported chip card reader (BBPOS Chipper 2X) e.g. the standard EMV transaction is very slow (15-20s), the VISA Quick Chip transaction doesn't work (with or without UI), and the stripe reader is not supported.
Would it be possible to support this tablet fully for EMV transactions, please?
Thanks much for considering!
Currently we need to two buttons for managing an order payment - create/edit customer profiles and make payment. Why not let the customer get to the edit customer profile from the hosted payment form. Then after initiating a payment, if they don't see the payment option in the profile list or realize expiration date is wrong, etc, they can handle it all without returning to our site, clicking another button to manage profiles, return to our site, and then click to try paying again.
It could be a button on the hosted payment form that brings up the hosted customer profile form and when the customer is done returns to the hosted payment form.
Like this forum post, I would like to offer two simple buttons to customer - manage profile and make payment.
The solution in the post suggested submitting the following idea - "Perhaps if you call the form with a profile ID, it automatically presents the list of saved payment methods to the customer, allowing the customer to pick one, or click a button to enter a new one (either for that transaction or to save in their profile)?"
The current documentation states for the payment form - "When the form is displayed in the browser, the 4 most recent payment profiles for that profile ID will be displayed. The customer can choose between these payment methods or choose to use a new payment method."
Why make this limitation? For the very few customers that we have that would have more than 4 payment profiles, why not a 'more' link and show them all or just show them all in most recently used order? Instead we have to read the payment profiles onto our site just in case the profile the customer wishes to use wasn't in the list.
We want to integrate this payment gateway in our project(android, ios and web) as following flow.
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.
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.
For getAUJobDetailsRequest, can you please allow pulling auto updater details on a daily basis instead of a monthly basis? It would be very beneficial for us to have more insight into what changes are being made sooner than the first of the month.
When a customer profile is created, the payment details are validated by sending through a transaction, if validationMode is set to liveMode. This transaction is not subject to IP address filtering as this cannot be set when creating a customer. This can create a situation where the account can be locked due to the fraud, which should be blocked by IP Address filtering.
See also issue raised here
There is currently a way to pull up all customer profile IDs, but there exists no way to filter the results by email or customer ID (except by pulling each customer profile individually by the returned IDs, but this would be undesirable given the implications on performance and the number of possible customer profiles). In the CIM we can manually perform a search that searches by customer ID or email. This would be useful to have for the API.
When the Add a New Payment Method form is displayed, via AuthorizeNetPopup.openAddPaymentPopup(), all fields are initially blank. Our site has already collected some information in the Billing Information section and we'd rather not burden the customer with entering it again; is there a way to pass information into pre-fill fields on the form?
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.
For Accept Hosted, when specifying hostedPaymentReturnOptions, there needs to be a way we can construct the url for the GET that includes values returned after successful authcapture in the receipt page.
When specifying name value pairs, we should be allowed to refer to DOM element values as variables and then substituted to construct the URL (and urlencoded) for the Continue button since the elements are present in that same receipt page as the button.
A suggested syntax is as follows:
The concept of variables could be generalized for use in other name value pairs as needed.
Thanks for considering.
Add webhook from profile.js to the hosting web page when saving an added/edited payment profile. Notifying the hosting web page of saving an added / edited payment profile would allow emailing our company when a client adds/edits a payment profile.
Send communication to hosting web page from profile.js function btnSave_onclick when added/edited payment profile saved. Currently communications are only sent to hosting web page when saving a single edited payment profile. I'd like to send communication to hosting web page when adding/editing multiple payment profiles.
I'd also like the IFrameCommunicator to pass paymentProfileID to the IFrames containing webpage so we know which credit cards were added or edited.
Rewrote idea to be clearer.