We're setting up a system that will use the XML API for Automated Recurring Billing with Authorize.net.
It looks simple enough to set up a recurring billing. But we have two features that do not seem obvious
* providing customers with details on individual payments
* providing notification to customers of expired/canceled cards
Anyone familiar with a mechanism to retrieve this info in automated form? We're considering
* just listing out assumed payments based on our own calculations the start date
* emailing customers based on the expiration date of the ards
But I'm stymed on how to figure out when a transaction failed due to canceled card (and automatically notify the customer).
Can anyone comment on how they handled this issue when implementing a subscription-based service based on Authorize.net?
Authorize.Net has recently published a new ARB method "ARBGetSubscriptionStatus".
You may now easily query the status of a previously submitted ARB subscription without the need to depend on the "Silent Post Method".
Example:
<?xml version="1.0" encoding="utf-8"?> <ARBGetSubscriptionStatusRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"> <merchantAuthentication> <name>mytestacct</name> <transactionKey>112223344</transactionKey> </merchantAuthentication> <refId>Sample</refId> <subscriptionId>100748</subscriptionId> </ARBGetSubscriptionStatusRequest>
You want to use Authorize.Net's silent post feature. It will notify you of all payments made through their system including declines and expired credit cards. Your script will then be able to suspend accounts and/or notify your customers that their payments has failed.
See these link for more info:
Handling Authorize.Net ARB Subscription Failures
All About Authorize.Net’s Silent Post
Handling Authorize.Net Silent Post with PHP
You need to use the Silent POST URL
ARBGetSubscriptionStatusRequest will not work. If the first transaction (or first transaction since the ARB profile was updated, either via API or manually) fails, the status of the subscription is set to suspended. Otherwise, the status of a subscription does not change when a transaction declines or a card expires.
Using the Silent POST URL, you'll be notified of successful transactions and you can use them to update your data such as tracking a next payment due date/expiration date. You can then run a cron job and if this field has not been updated, you will know that the card was cancelled or expired.
In the event that it is still an active card but gets declined, you'll get notified as such at the Silent POST URL
Related
I want to test the following scenarios which are included in the stripe subscription status documentation.
Can anyone please suggest a test card in stripe to test it?
Scenario 1
Incomplete_expired- The initial payment on the subscription failed and no successful payment was made within 23 hours of creating the subscription. These subscriptions do not bill customers. This status exists so you can track customers that failed to activate their subscriptions.
Scenario 2
Unpaid- The latest invoice hasn’t been paid but the subscription remains in place. The latest invoice remains open and invoices continue to be generated but payments aren’t attempted.
You should use a test card where the payment will be declined for the initial subscription invoice payment. There's a full list here, but 4000000000000002 will return a generic card_declined error which should be sufficient for this testing case.
Have a look at the SO question: Simulate Stripe Subscription Renewal Failure
The idea is to create a user with a valid payment method and then change the payment method later on via the dashboard for example.
For incomplete_expired - just pay with card which need 3d secure like 4000002500003155 and don't make card authentication, subscription will move to incomplete after 3 hours, after 23 hours subscription status will move from incomplete to incomplete_expired.
For unpaid status Stripe says some additional setting should be applied
https://stripe.com/docs/api/subscriptions/object#subscription_object-status
I have created shopify app and setting up billing Api. In the App, I want to apply trial period of 20 days. I have created the charge during the app installation and send customers to confirmation url so that they can accept or decline the charge.. So I want to know that if customer decline the payment charge, then can he uses the app featurs till trial period?
If a customer declines the subscription, you still get the confirmation URL callback. Examine the charge. The status will say declined. At this point you can kill off their DB token and destroy their session. This will ensure they cannot use your App as they declined the terms.
It is one bad aspect of the whole billing scenario. I have lots of customers that are faced with a question they don't read. So they assume the trial you offer for free is activated by declining the subscription. Silly customers... still cannot operate the Internet :)
I am new to the paypal api, but have integrated it into my site. Every transaction has 2 receivers using the adaptive payments api. Every once in awhile I get an ipn response with status of INCOMPLETE. Reading the documentation it says this status is because
Some transfers succeeded and some failed for a parallel payment or, for a delayed chained payment, secondary receivers have not been paid
Why would only one transaction work? Only the first recipient is getting the money causing problems. What is the best way to handle this? Anyway to immediately refund the buyer with the first recipients payment?
You could reverse all payments if any of them in the request fail using the reverseAllParallelPaymentsOnError parameter.
xs:boolean (Optional) Whether to reverse parallel payments if an error
occurs with a payment. Allowable values are: true – Each parallel
payment is reversed if an error occurs false – Only incomplete
payments are reversed (default)
When Payment fails in Magento the order statues is set to incomplete because it is waiting for the payment, so what is the best to integrate with and ERP system the orders when completed?
Is the Cron the only possible way?
Do I really need to be asking Magento every hour if the orders are completed?
Isn't there a event based api for this?
Thanks in advanced.
Yes Cron is the best way. Assuming that you are using many payments methods, like Skill or Paypal, the process is not immediate. Let's see this example:
1 - The user checkouts and selects PAYPAL
2 - The order is saved in Magento as PENDING - PAYMENT
3 - Imagine then that is Paypal the CARD is expired or not approved then the client goes for all this process of adding or changing another card to paypal, only after this change the client can finished the process
Until the payment is done, the order stays as PENDING PAYMENT
So with a CRON you can keep checking all orders and if this client actually finished the order, on the next CRON call the integration with the ERP can be made.
What also happens is that is the client gives up on paypal this order will stay pending forever. You need to decide what to do with this orders.
I have a subscription based website that interacts with a 3rd party system to handle the payments. The steps to process a new subscriber registration are as follow:
The subscriber enters his/her details in the subscription form and click on the submit button.
Assuming the details specified are valid, a new record is created in the database to store these details.
The subscriber is then redirected to the website of the 3rd party system (similar to paypal) to process the payment.
Once the payment is succesful, the 3rd party website then redirect the subscriber back to our website.
At this time, I know that the payment was succesful, so the record in the database is updated to indicate that payment has been made successfully.
A problem that I have found occurring quite often is that if a subscriber pays but does not complete the process correctly (e.g. uses the back browser, closes the window), his/her record in the database doesn't get updated about this. Accordingly, I don't know if s/he has paid by just looking the record and need to wait for the report from the 3rd party system to find this out.
How do you solve this problem?
PS. One of the main reasons to store their details into the database before the payment process is done is so they can come back to complete the payment without re-entering their details again. For example, when their credit cards were rejected by the 3rd party system and they need to sort this out with their financial institution which may take a while.
The third-party payment system should inform you of the successful transaction regardless of what the user does.
For example, in PayPal, an IPN (instant payment notification) is sent to your server as POST data to a URL that you specify. Your server then verifies with Paypal that the transaction is genuine, and if so, updates the database record to indicate the subscription is valid. At a point in the future, PayPal may or may not then redirect the user back to your website. (The "may not" can occur in cases such as the user closing their browser, hitting Back, or jumping to a new URL)
Note that this "conversation" between Paypal and your server is independent of the user's session - it is a "private conversation" between you and PayPal about that user's transaction.
Obviously there can be communications outages and server failures, so if Paypal does not get the validation request from your server immediately it will periodically send retries to your server to ensure that the transaction is eventually completed.
If your payment system doesn't have at least some basic mechanism for ensuring transaction reliability, then choose a different provider. Chances are that they do, but you will have to implement things correctly on your server to be sure that the system works properly.
P.S. It is quite normal to require a user to log in (and thus be registered in the database) before they initiate any financial transaction. You need to gather all the relevant information before they go to purchase, as after the purchase you have no way of guaranteeing that they will return to you to provide any further information.