I'm currently integrating into 2co.
Before redirecting the client to 2co checkout page, I book the goods in my system for a moment(10 minutes) and they are not available for this period for other clients. After the time elapsed, they'll be auto unbooked.
But at this moment do I have any influence on the payment process which actually is going on in parallel in another place? From what I've read, I only receive the info about the result of payment when the user(client) has successfully(or not) finished his work.
Is there any timeout parameters I can set before the payment or special links I can refer in the case of timeout occured?
The 2Checkout transaction fees are not taken from the sale until it deposits (settles). When selling intangible products or using the third party cart parameter set, the sale will not deposit for at least 24 hours. If you are selling tangible products with the Pass Through Product parameters or Plug and Play parameters, the sale will not deposit until you mark it as shipped.
The buyer's 2Checkout purchase session will expire after 60 minutes. So you could pass in your custom cart identifier using 2Checkout's merchant_order_id parameter, release the booking after any time interval you choose and if the buyer completes the sale after the booking has been released, decide whether or not you want to refund using the refund_invoice API call based on the cart identifier passed back from 2Checkout with the merchant_order_id parameter.
As far as handling the passback, you can either use the initial passback to your approved URL that occurs when the sale is completed, or you can use the 2Checkout Instant Notification Service Order Created message. If you use the ORDER_CREATED message from the INS, the value you pass in with the merchant_order_id will be passed back using the vendor_order_id parameter on all INS messages pertaining to the sale.
Let me know if you would like some help implementing this.
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 need suggestion for paypal pro API which allow me to pass variable amount each month. For some months,it can be zero too.
I tried with UpdateRecurringPaymentsProfile but it gives me error of 11592 (Subscription profiles are not supported for recurring payments).
Please someone help me with easiest solution.
Based on the error you mentioned it sounds like you're using a PayPal Standard Subscription button, not Pro. If that's the case, then as the error says, you cannot update standard subscriptions with the APIs. You would have to use the recurring payments API to create the profile in order to then update it.
That said, you won't be able to do variable amounts with recurring payments profiles. you can only raise them by 10% every 120 days, so that typically doesn't work with what you're trying to do.
Instead, you'll need to use reference transactions. So if you're using Payments Pro that will be real simple. You just pass in the transaction ID of an original authorization or sale transaction along with a new amount you need to charge. PayPal uses the card details on file to process the new amount.
If you're using DoDirectPayment then you'll use DoReferenceTransaction for the future payments. If you're using PayFlow you would use the PayFlow API, of course, and change the parameters to match a reference transaction request.
You can also do the same thing with PayPal Express Checkout, but in that case you'll need to include billing agreement parameters in the SetExpressCheckout request, and then you'd use the billing agreement ID you get back from that in the DoReferenceTransaction request.
In any case you'll need to build your own script to run everyday, pull profiles that need to be charged, and charge them accordingly.
I'm setting up my first Shopify store and would like to offer a free trial of a product. The basic idea is the customer is shipped the product at no charge and has so many days to try out and return the product. If the product is not returned within the time period they are charged the amount agreed upon up front.
Within Shopify there is only the option to capture payment immediately or to authorize and then manually capture payment later (7 day auth limitation).
What I would like to do is validate the credit card, but not pre-auth, then the ship the product to the customer for try out. If they decide to keep the product then I charge them 30 days later as agreed by the customer.
The method I want to use with Shopify is the same as detailed by Braintree here
https://support.braintreepayments.com/customer/portal/articles/1080637-collect-payment-at-a-later-date-aka-extend-authorization-
in the section "Save and Verify the Card, Charge Later".
You can use the option as you see it: authorize and then manually capture payment later
As an alternative, you could always capture the money, and if they actually do return it, refund them the money. That is how all TV sales work and they make bazillions doing that, so why not follow their lead?
i didn't find any information about life time of payments with intent "sale". If a user cancel's payment by closing the paypal window, then i should be abled to continue payment by looking up the payment via api and redirect him to the approval url. But this works only for a certain time span. I'm abled to look up payments from yesterday, the response tells me about a payment state of "created" but after redirection to the approve_url paypal's website says:
Your Session has ended.
This transaction has expired. Please return to the recipient's website to complete your transaction using their regular checkout flow.
I guess i should create a new payment in that case. But how long should i wait before creating a new payment, because payments with age.. - lets say about 1 hour are still valid?
TIA
The user has three hours to approve of the PayPal payment before a new payment must be created.
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