I’m integrating authorize.net into my web application. I’ve used the direct post method (DPM)to charge the account initially. However, for each transaction I also need to set up automated reoccurring billing. How would I go about doing this without asking for the information again, particularly when after DPM posts the initial transaction, the credit card data is no longer available?
I also would like to get the status of each reoccurring transaction so it can be confirmed and followed up on if necessary.
You can't do that with DPM as it takes the user's credit card information off of your website so you don't have access to it. If you want to make an initial payment and then use ARB to create a subscription you need to use AIM with ARB.
You need to use the ARB interface in order to do recurring transactions but there are a lot of problems with it, like lack of support (send an email and wait a couple of weeks for a non-helpful response for example) and weak documentation.
Documentation for SOAP interface for Authorize.net ARB:
http://www.authorize.net/support/ARB_SOAP_guide.pdf
And for the XMl interface:
http://www.authorize.net/support/ARB_guide.pdf
ARB programming documentation:
http://developer.authorize.net/api/arb/
I just switched off of Authorize.net to USAEPAY. Here are some reasons why:
1. When you use Authorize.net ARB, your customer comes on the site to sign up, and you send the ARB request to create the subscription and you get back a success code so you give the user the subscription. Then later that night they actually try to collect the first payment and a lot of times this fails, so you get a spreadsheet emailed to you the next day about the problem. This is terrible because now you lost the opportunity to say to the customer at sign up time that the card is declined. Goodbye sale!
2. I don't know if they added this recently but they didn't have a way to verify if a customer's credit card is still valid. Imagine 3 months into a subscription the card is over the limit, or cancelled, or expired etc. You don't know so how do you prompt the customer to put in a new card? You just stop getting paid, unless you want to manually open these spreadsheets and start emailing customers. YUCK.
USAEPAY works much better, the API is easier, its much better documented and you get email responses in 1-2 days and its less expensive. For example, you can query USAEPAY to get a list of successful payments, and verify that you shouldn't deactivate the account for non-payment:
http://wiki.usaepay.com/developer/soap-1.4/methods/getcustomerreport
Before you go too far with AuthNet I highly encourage you to save yourself a lot of pain and contact FranchisePaymentNetwork (FPN) to get set up with USAEpay.
They can even POST BACK to your website to let you know if a transaction is successful or not for recurring billing transactions and you can query it to verify that customer payments are getting collected so you know if you should expire an account or not.
I am not affiliated with USAEpay or Franchise Payment Network except as a satisfied paying customer / consumer of their services.
Related
I'm hoping that someone here can assist me with this issue. Stripe support has been underwhelming thus far.
We have a Primary Stripe Account setup in the US
We have customers that will be based out of MX that will connect to the US accounts.
From what we understand here: https://stripe.com/docs/connect/cross-border-payouts there are 2 main criteria that need to occur
We need to make these accounts "Custom"
We need to use the "recipient" option for the account's service agreement.
We also cannot request any other "Capabilities" such as "Card Payments" when setting this up.
Moreover, we have noticed that the moment we use the "Custom" option with Recipient agreement, customers do not have the ability to "Sign In" to their existing Stripe accounts even if they have one. The system always forces them to go through a "new" account setup process. Per Stripe, we are responsible for managing everything including verification of the customer and the customer is NEVER aware of the Stripe account's existence. This has been a hard pill to swallow for some of our larger customers who already have a Stripe account.
Say, we overcome that objection, and say people create new accounts. Now, we're running into a whole new series of problems.
We understand that Stripe requires us to perform separate charges and transfers. Great, we use transfer groups and transfer destination.
However, we also want to use the on_behalf_of parameter so that we attribute the transaction to the connected account for reasons explained here: https://stripe.com/docs/connect/charges-transfers#on-behalf-of
This is where the fun starts. It appears that if you use on_behalf_of, you cannot use "Automatic Payment Methods".
If you specify "card" as a manual payment method type, it will tell you:
You cannot create a charge with the on_behalf_of parameter set to a connected account with transfers but without the card_payments capability enabled.
However, the kicker is that we cannot request card_payments capability for the custom/restricted accounts. So this is a catch22.
So now, we cannot use On Behalf, and essentially, we're acting as the account of record, which is raising alarms in our accounting department.
In addition to that, our customers want to use OXXO, understandably so. This works fine in DEV mode, but when we enable Production, it tells us:
This payment method (oxxo) is not activated for the account specified in on_behalf_of. You can only create testmode oxxo PaymentIntents. You can learn more about this here https://support.stripe.com/questions/i-am-having-trouble-activating-a-payment-method
So, essentially, we are unable to use OXXO w/ or w/o on_behalf.
This makes us think if there are better ways to resolve this issue. We have been trying to get through to Stripe support and their responses have been circular, almost meaningless as they keep pointing us to the documentation and we keep poking holes in their documentation.
Am I missing something here? Looking to see if someone else has had these issues.
Cross-border Payouts as a feature allows US platforms to transfer funds around the world in more countries than Stripe officially in. For example you can accept payments from a customer on your platform and then sends funds to a connected account based in South Africa or South Korea even though Stripe doesn't (at the time of this answer) support those countries for payments.
The overall feature relies on a different type of "agreement" between you and the individual/business you are sending funds to. To do that you have to explicitly set recipient as the service_agreement parameter.
When you go down that path, you can not use on_behalf_of at all. Using on_behalf_of changes a lot of things such as where the payment is being "made from" which Stripe documents here. For that to happen in South Korea or South Africa, Stripe would have to be able to operate and accept payments there. But they can't, and that's why Cross-border Payouts exist in the first place: to let you send funds in countries where Stripe doesn't yet operate. So not using on_behalf_of is entirely expected.
Now, if you don't use on_behalf_of, what you are really doing here is accepting payments yourself, on your US account, through the US. So this limits you to the payment method types that Stripe supports for US accounts. This means you can not use Oxxo for Mexican customers or Konbini for Japanese one. This is a limitation that Stripe likely will lift over time but it's not available today. For example you can accept a lot of European payment methods from the US now which wasn't possible in 2019. In the future, those things will get easier, it's just not the case now.
What I don't fully understand, is why you would go down that path. You clearly say you don't want to be the "merchant of record", you want to do local acquiring, etc. My read is that you simply want to use Destination charges with on_behalf_of. This is supported from US platform to a MX account already. This is something Stripe already supports by default with the "default" services agreement.
While I tried to help with my knowledge, this is really something you have to discuss with Stripe's own support team. They are the only ones that can look at your account details, discuss your business model and understand if they can support you.
We would like to know how we can test stripe in LIVE for an e-commerce website? The site basically is an e-commerce website and courses are purchased online, how do we test LIVE transactions without using real-time credit cards in stripe?
The purpose of Stripe test mode is to ensure that you get your code into a perfectly working state, and that each type of transaction you are dealing with is fully covered. You can even validate that WebHooks are working by pointing them at your application's test API endpoints.
There's not really a way of 'testing' inside of the live environment as such - typical practice would be to make a real transaction using a company credit card, or one that you are in control of. You can then logon to Stripe Admin and refund the payment once it succeeds.
This is the same with most payment gateways, although there are some that have test mode built into the live API, and used via a specific header, parameter or tracking identifier. Although, this is really just the same end result - you are still testing in test mode.
Use a 100% off coupon and no monies will be transacted. This should allow you to test the flow of things in livemode and make sure everything is in sync without posing a threat to Stripe as a company or your Stripe account.
Note: If you're testing a stripe subscription, you should immediately end the subscription, and delete the "customer" before you forget and it's ACTUALLY processed the next billing cycle.
Here's an example of creating and using 100% off coupons.
Disclaimer: I have NOT tested this method. But I believe my theory is correct.
You can use Customer Credit Balance (https://stripe.com/docs/billing/customer/balance) and use real credit cards to do some final testing of your live implementation. I just did it, it works perfectly and no charge is being done.
Good luck!
This can be accomplished from the Stripe dashboard in one of two ways. The set up for both methods begins in the same way.
Navigate to the Customers section of the Stripe dashboard, and create a new Customer object for yourself (or your employees)
Once you've created the new Customer, add the card details for the real card that you or your developers will using to test the live Stripe integration. This step is necessary because Stripe uses the card number to associate any test payments you make with the Customer you just created.
With the new Customer still selected, you'll see an Actions dropdown to the top right of the Overview page.
From here, you can select one of two solutions to waive costs for your new Customer:
Create a permanent 100% discount by selecting Apply Coupon and following the New Coupon link to create a coupon that can then be applied to your Customer's account
Create a credit balance for your Customer by selecting Adjust Credit Balance and setting it to a sufficiently high value
I recommend the first as it allows for more control. In particular, coupons can be set to never expire, unlike credit balances that will eventually hit 0 and require you to remember to reset it.
To prevent abuse or avoid creating an exploit for potential attackers, you can even set the coupon to be redeemed only as many times as you intend to redeem it, preventing it from being applied by anyone who doesn't require it to test your Stripe integration. In the below screenshot, I've set it to be one-time use.
I am working on a software that is to be used by businesses which make about $0.5mil revenue per year. I would like to incorporate into the software the option for my users to accept card payments from their clients. So far it seems I have the following options:
Manage multiple merchant accounts on behalf of my clients, however this has a few drawbacks. I would, for example, like to charge some small fee to cover the costs (about 0.1%) which I cannot accept if the payment to my user doesn't go through some stage that I can control where I can deduct the fee and send it my way. Also, about 50% of the mentioned revenue is paid for by credit or debit cards so a volume of $250,000 might not be enough to cover the fees set by the account provider.
Send everything through a merchant account that I control and then distribute the funds to the users. This, however, seems like a very small scale solution at best with the average number of payments per user per day being around 15.
The end result should be that the user enters a price in the software, this gets sent to a card reader where the user's client inserts their card and makes the payment. The amount charged includes all the fees associated. The amount paid will then be sent to some merchant account where my fee will be sent to me and the merchant fee will be deducted, the rest will be sent to my user's account. The whole point being that the user doesn't have to bother with setting up merchant account or card reader and simply gets a card reader from us which connects to the software and can immediately accept payments.
I sincerely hope I am missing something but I would appreciate any help with finding a way how to charge clients of my users and take some small fee.
So as it turns out, the best way to do this is using Stripe after all. If anyone is ever concerned, this is how I solved the problem.
Stripe is currently rolling out Managed Accounts of their Stripe Connect which can be used to effectively manage Stripe accounts for my customers. Therefore, once a user registers for my payment program, I create a managed account for them without the user knowing at all. For incoming Stripe payments I can then use the destination property as the id of the account where the money should go and specify an application fee which will be charged to my own account.
From there on the only problem to solve is that Stripe only supports online payments which can be overcome by using for example Payworks, however so far their service has been pretty terrible so this may be a weak point in the system.
I'm moving my site's payment processing from Google Checkout to Google Wallet (Digital Goods API), but I'm running into an issue involving payment notification. My goal is to only send licenses to customers after orders are charged, but I don't see how this is possible.
Right now I'm sending licenses to users when I receive the postback JWT, but this isn't the behavior that I want, because, according to my tests so far, it takes about 30-60 minutes to actually charge the customer after the purchase (until then, the order is in a CHARGEABLE state). This is a problem because I've frequently had orders be cancelled before they are charged - I obviously don't want to send out licenses when this happens.
So my questions are:
1) Why aren't customers charged immediately? According to the documentation, "Google Wallet for digital goods orders are charged automatically", but there's no explanation of the delay.
2) Is there any way to receive a notification after the customer is charged? The postback and the success callback that are described in the documentation are both no good for this, because they're both triggered when the order enters the CHARGEABLE, rather than CHARGED state.
I'm hoping that there is some system like the Google Checkout Notification XML API, where different notifications are sent out at each stage of the purchase process, but the Google Wallet documentation makes no mention of such a system.
3) On a related note, is there any way for me to get email notifications when orders are complete? Google Checkout did this, but Google Wallet does not seem to offer this option.
3.) I suggest you send yourself an email through the success_handler via javascript. I'd probably use and ajax call like jQuery's .post and pass all the values such as order ID and so on to a php file and send the email from there.
https://developers.google.com/commerce/wallet/digital/docs/jsreference#successhandler
1+2) Here's how I understand it: CHARGEABLE means the credit card has been authorized, and whatever needs to happen between the banks and all that is in progress. CHARGED means google has actually received money from the banks. So the explanation of the delay (I believe) would be the same as if you buy something at the store with your debit card, then look at the account statement and the charge still is in there as "pending". I am under the assumption that you can pretty much rely on the CHARGEABLE state and consider it paid. Whatever happens after that is probably the same risk as when someone used a fraudulent credit card, and the charge gets returned later, or the customer disputes the charge on their statement.
How did your customers cancel the charges? If that happens, could you revoke the license?
My client is using moneris as our payment gateway for a new subscription based website that I am working on.
I will be using the language PHP
I've looked through their documentation for PHP api and am comfortable with how it works, it seems very straight forward.
One thing was missing in the documentation for me though. There is mention of how to start a recurring payment, how to update a recurring payment, but no mention of how to query a recurring payment?
Some payment gateways allow you to have a POST back URL of sorts that get updates on recurring billing status. This does not seem to be possible with moneris.
How do I go about automatting the process of tracking recurring payments with Moneris? I'd like for my customers to log in and be able to view their transaction history on my site.
This information will also make it easier for me to know when to close accounts. Ie. when a payment fails to go through, or a credit card expires? I don't want for my cleint(owner of website) to have to keep track of the recurring payments and cancel accounts manually?
I got an answer from Moneris:
Hi David, We currently do not have a reporting API or any way of
posting the information from our recurring payments back to your
server. It is something that has been mentioned previously and is
being looked into. We do not have a current ETA on such a solution.