I'm working with a web application that allows our customers to integrate with Apple Pay on the web. The customers setup their own Apple Pay merchant accounts, a third party handles the actual payment processing, but our servers are responsible for web hosting and obtaining the payment sessions.
Sporadically for some customers, we receive a 400 error when obtaining the payment session, with a message of:
Payment Services Exception merchantId={id} unauthorized to process transactions on behalf of merchantId={id} reason="{id} never authorized mass enablement transactions to occur via {id}"
(Here all the {id} values will be the same).
Despite sounding like a configuration issue with the account, this will only affect some otherwise identical requests. (Same domain, merchant identity, etc.) It affects some customers but not most; when it does affect a customer, somewhere between 10% to 50% of the session requests will fail in this manner. We have several customers never hitting this error even after processing thousands of transactions.
The phrase "mass enablement" doesn't seem to show up in apple's documentation, and the exact phrase "never authorized mass enablement transactions to occur" produces no results at all when searching the web. The closest I can find is this thread on Apple's developer forums but its not an exact match, and has no answers in any case.
Has anyone seen this error and resolved it?
(I'm also pursuing this matter via Apple support; if that eventually proves fruitful I'll update with an answer.)
This happens when a domain has been registered to a merchant using Apple Pay's Mass Enablement API.
The domain (not the merchant ID) will need to be deregistered by whoever claimed the URL before you are able to proceed, although I would expect Apple Pay's support team would also be in a position to remove the registration for you.
https://developer.apple.com/documentation/applepaywebmerchantregistrationapi
I got this error when using my localhost (not registered for Apple Pay) as the front end of the website making a session token request via the back end whose domain had been registered for Apple Pay.
There are few things that needs to be considered here:
Are you using the correct TLS config (the cert and the key) to make the request ?
Are you using the correct merchant validation file send to you while approving mass enablement for the merchant ?
Once you confirm on these 2 things, there's a hole in the documentation provided by apple.
After hitting https://apple-pay-gateway.apple.com/paymentservices/registerMerchant with above proper config and data this requires a param called partnerInternalMerchantIdentifier this is a unique merchant id that you can use on your end.
register merchant
By default, to get a payment session (https://apple-pay-gateway.apple.com/paymentservices/paymentSession) we might send the primary merchant id that we use for merchant registration in above API which is fair as per their docs.
docs
But to make it work we need to send the partnerInternalMerchantIdentifier which we sent in the above API. This acts as a sudo merchant id to get payment sessions.
Get payment session for newly registered domain
Related
I am after the best practice for handling incomplete stripe connected account onboarding.
When onboarding goes smoothly, everything is simple. But there are fiddly edgecases everywhere, which results in a lot of permutations of values for account requirements
These include
current_deadline
currently_due
disabled_reason
errors
eventually_due
past_due
pending_verification
This creates a lot of complexity.
I need a simple way to:
figure out if the connected user needs to be notified of something (i.e. that they need to give more info), and
what to tell them.
My current strategy is to check if errors is empty, and if not, simply display them along with a link to manage the user's stripe account so they can address the errors.
But I'm worried this strategy will miss things (perhaps minor things that could be addressed before they become errors).
TL;DR I suspect most users will onboard without any problem, but for the few who do have issues, I want to ensure the app notifies them that they need to address them. What is the best way to do this? (using the information in requirements or other info)
When handling identity verification manually using the API, a simple way to check whether your connected user might need to be notified to provide more info is to look at the charges_enabled and payouts_enabled properties on the user's account object. If either of these two properties are false then you might need to reach out to the connected user for more information.
In cases where the connected user's charges and payouts are disabled, you would use the disabled_reason property on the requirements hash to learn the reason why charges and/or payouts are disabled. The possible disabled reasons are all documented here, but I'll list them out nonetheless:
action_required.requested_capabilities You need to request
capabilities for the connected account. For details, see Request and
unrequest capabilities.
requirements.past_due Additional verification
information is required to enable payout or charge capabilities on
this account.
requirements.pending_verification Stripe is currently
verifying information on the connected account.
rejected.fraud Account is rejected due to suspected fraud or illegal activity.
rejected.terms_of_service Account is rejected due to suspected terms
of service violations.
rejected.listed Account is rejected because
it's on a third-party prohibited persons or companies list (such as
financial services provider or government).
rejected.other Account is rejected for another reason.
listed Account might be on a prohibited persons or companies list (Stripe will investigate and either reject or reinstate the account appropriately).
under_review Account is under review by Stripe.
other Account isn't rejected but is disabled for another reason while being reviewed.
Using the disabled_reason, you can assess whether the user needs to be notified with a request for more information (i.e., requirements.past_due), whether they need to be notified for another reason (e.g., rejected.listed), or whether you need to make programmatic changes to the user's Stripe account (e.g., action_required.requested_capabilities).
I am growing frustrated with the lack of features and poor documentation of the Google Wallet for digital goods subscription API.
My question is the following:
If Google wallet sends a postback to my URL, and I do not acknowledge the payment (send status 200), does the payment get refunded or not appear on the card statement in the first place?
It seems rather strange that there is no way to programmatically cancel subscriptions. A work around would be to manage subscriptions on my end and only accept the postback payment if their subscription is valid. This would of course be frustrating to a user if they canceled a subscription, yet they still see a charge to their card and then a refund. I would like to avoid that.
Thanks in advance again everyone.
I'm not a Googler so this is subject to being crucified :)
To get an official response, it would be best to contact Google directly - you should see a "HELP -> Contact Us" in your Wallet Merchant Center.
Important: If you specify a postback URL, your server must respond promptly and correctly to the HTTP POST messages that Google sends for each transaction. Otherwise, the transaction will be canceled.
REF: Official documentation on handling postbacks
This somehow/probably relates to the old question in credit card processing of the difference between an AUTHorization and an CHARGE (aka "capture").
An AUTH for x amount would need to be sent for processing. Otherwise, how would Google send you a positive result for the transaction (aka Google would send you a postback after such successful "Auth" transaction for x amount - re: does account have enough funds to cover x)?
So there would be a "pending AUTH" for x value on card holders' account, subject to "capture" (finalizing, turning that AUTH into a CHARGE) at some later time (perhaps after you successfully acknowledge the postback).
What Google does (e.g. "Void" or "never capture") to that pending AUTH if you don't acknowledge (aka "...transaction will be cancelled"), or whether or not the above scenario is actually what occurs in Wallet for Digital Goods, can only be answered by Google. The above is only a personal (mine and mine alone) insight to standard credit card processing...
Hth....
I am new to integrate Google Wallet and there are some confusion and questions related to that given below:
Is it possible to add multiple items for Google wallet?
How to handle discount by API?
What's the parameter in JWT response on postback URL for success and failure transaction?
Is refund functionality available for a transaction by API call?
Anyone have idea about this. Thanks in advance.
Can you clarify which specific API (Instant Buy or Wallet for Digital)?
Is it possible to add multiple items...
Digital - no, you can however "bundle", see this post for clarification.
Instant Buy - it's just a "layer" on top of your (pre) existing purchase/ordering processes and handles (just) the payment data of a Google Wallet user. The "order details" is something you control. See sample of data you send.
Discounts by API
By API - no. You can pass whatever (pre-calculated) value in both APIs.
Success vs. Failure Postback
Digital - Google will only send HTTP Post to your server URL on successful transaction. See #5: "Google sends an HTTP POST message to the postback URL whenever a purchase completes..."
Instant Buy - not relevant. You are processing the transaction, unlike in Digital where Google is. Instant Buy in a nutshell provides your web site, secure access to a Google Wallet user's data. You need to have your own merchant account/processor, be PCI compliant, etc. That said, you will have the success or failure info that you actually have to send to Google - they need to know if you have successfully processed or not (yup, it's the other way around).
Refund by API
By API - Unless a Googler says otherwise, AFAIK, not at this time, for both APIs.
On that note, for Instant Buy, it's actually unclear to me how to "inform Google" when performing a credit or refund. Its still a "private API" (not GA) so I actually haven't seen its "guts". It's understood that since the merchant uses their own processor that a credit/refund is the same procedure, but letting Google "know" about it (days/weeks after the fact) is something I personally have no actual info on..sorry...I can assume some "button" in merchant center for Instant Buy, but that's just a guess....
Hth....
W.r.t InstantBuy Refunds:
The Refund happens on the virtual one time card that is returned by the Google API. The refund on the card can be done by using any backend payment processor. Once the refund is made to the card, it hits the user's backing card.
I think that the Dwolla API sends the wrong transaction ID in notifications. In a normal dwolla money transaction, two transaction IDs are created (this is weird to me, but that's how dwolla does it). Because these two are created at the same time, they are always (in my experience) consecutive numbers.
So e.g. if account X sends money to account Y, Y will see transaction id M, and X will see transaction id M+1.
But Dwolla's notification webhook will send Y details of the transaction with id M+1. While ID M+1 is still unique to this transaction, ID M+1 cannot be used by Y via the API - because M+1 is supposed to only be used by X.
Here is a specific example:
Via my webapp, I send money from my personal dwolla account to my organization's via the off-site gateway api.
My webapp is sent the transaction details in both callback and notification form. The transaction id generated by step 1 is 1431566. This is the transaction id sent to both callback and notification. My web app stores this Id for future use.
Via my webapp, I decide to refund my personal dwolla account from my organization's so:
My webapp tries to query dwolla about transaction 1431566, to get the SourceId, but this fails - dwolla reports "Transaction not found for account". My automatic refund cannot continue without an ugly kludge like subtracting one from the Id and trying again.
The manual workaround is to login to my organization's dwolla account via the web interface. Here I can look for the transaction based on datetime and I can see that the transaction ID is actually 1431565 (correctly reported in the web interface). If I go into my organization's database and replace 1431566 with 1431565, I can repeat step 4 and it works this time. After that I can initiate a send() and the refund goes through.
I reported the same problem here before dwolla moved support to stackoverflow: https://getsatisfaction.com/dwolla/topics/callback_and_webhook_notification_sent_wrong_transaction_id_off_by_one
I figure it will be fixed faster if other people have the same problem. Or maybe I'm missing something obvious and someone will point it out.
Thanks to Michael's help, we were able to get around this issue by using the receiver's OAuth token when getting the transaction details instead of the sender's OAuth token.
For example, say I send some money using the API and transactions 1202 for the money sender and 1201 for the money receiver get created. If you make the API call to get details for transaction 1202 but use the receiver's OAuth token, it will give you details for transaction 1201, including fee information.
I'm not sure if the situation is exactly the same since we are acting as the facilitator between two transactions, so no guarantees that this will work in your situation. But it's worth a try.
So, your application's key & secret can access the transaction ID posted to you by passing the transactionById() method your application's client_id and client_secret, as opposed to the oauth_token. Meaning, when you poll for the transaction, instead of querying this URL:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?oauth_token=x
Query this url, instead:
https://www.dwolla.com/oauth/rest/transactions/{transaction_id}?client_id=x&client_secret=y
Makes sense?
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.