I've used Paypal iOS SDK for Payment purpose, since a week I've been facing a problem with payment process. Getting an error like
"Declined by Fraud Service: 11611-Transaction blocked by your settings
in FMF".
Since a year it had been working fine and I haven't changed anything from its integration part but recently (suddenly) I'm getting an error. Is there any update required with settings of iOS SDK?
I tried to look around this link (https://developer.paypal.com/docs/classic/fmf/integration-guide/FMFIntro/) but could not find exact solution for mobile app. Pl. help if any one is aware about this error.
I found an answer to this question. There is no technical solution of this problem. Question has an answer to a question. Reason for this error is Activation of Fraud Management Filters. Fraud Management Filters (FMF) filters fraudulent transactions.
Following sample possible reasons provided by Paypal for such error:
Country Monitor filter, which identifies transactions based on the
country of origin
Card Security Code Mismatch filter, which identifies transactions with differences in the credit card security code. (When a customer tries to checkout using an incorrect/mismatch billing address, cvv or expired date registered with the card.)
Maximum Transaction Amount filter, which identifies transactions whose value exceeds a specified amount
Total Purchase Price Minimum filter, which identifies transactions that are less than a specified amount
In my case actual issue and reason for this error was: Customer had
provided wrong/incorrect information about payment card, which was
filtered by Paypal as fraudulent activity. And rejected transaction
for that customer.
I solved this problem by informing customer to register this information in its account and verify the same to Paypal.
Related
I have a service (iOS app) that works by letting users use a real-world service many times, but each time it's impossible to know the cost of each 'session' up front.
I'm aware that Apple Pay allows for a single checkout with an unknown amount (will be shown as 'pending'), but does Apple Pay also support a method where the user can 'authorize' an app once for (many) future update checkouts, without the user having to manually accept them each time?
No, this is impossible. Same as with credit card
The problem is that Apple does not charge money for the developer account. I tried to pay twice but I didn't have success. Apple says "Your purchase may take up to 48 hours to process." but nothing happens.
I assume that the Card Holder (Visa, Master Card) and developer name are different that is why Apple does not take the money.
So I want to reset enrollment to the first step, so I can write the same name as Card Holder name.
There may be many issues behind the scene in your case,
Apple might not be able to obtain the payment from the card you have submitted .
To prevent further issues:
• Before placing the new order, notify your financial institution that you are expecting a charge from Apple and confirm that your billing information is accurate.
• Be sure to use a payment method that is accepted for developer purchases in your region, as presented during the purchase process.
• Confirm that all payment details match the information on file with your financial institution when submitting the new order.
If there is mismatch in the card holder detail and the developer name, there may be chances that Apple might ask for ID proof of the developer(Rarely).
You can always contact the Developer apple customer care and check the issue , which will be resolved within 2 business working days.
Once you have made the payment , you have to wait upto 48 hours to process . You will not have option to reset the enrolment in this time.
I have successfully implemented subscription validation for Google Play, but I am struggling to understand the validation flow for iOS auto-renewable subscriptions and would like to ask for your help. Here is how high-level logic for Google Play:
New subscription validation
User purchases subscription in the app.
A SubscriptionRequest is created in my Firestore database, which includes the UserID and the token of the transaction.
A cloud function picks up that SubscriptionRequest and queries the relevant Google API using the token to get the subscription details. This is done using the googleapis Node.js libary.
The latest subscription details are saved in Firestore as a Subscription, including the token (as linkedPurchaseToken) and the UserID.
The expiry date of the subscription is evaluated and, if it is not expired, the User in Firebase is updated and the flag hasActiveSubscription is set accordingly (including Google Play identifier of the subscription, e.g. monthly_sub, or annual_sub, and the platform, in this case android).
Google Play Developer notifications
Notification is received via a Pub/Sub cloud function.
The corresponding subscription details will be fetched using the relevant Google API and the token from the notification.
If no Subscription with that token (as linkedPurchaseToken) exists in the database, we'll try to get find the existing Subscription in our database using the linkedPurchaseToken from the subscription details that were fetched in (2).
If still no Subscription can be found in the database, that obviously means that it's a new subscription, which will be handled exclusively via the New subscription validation process described above. The reason for this is that I am otherwise unable to link my UserID and the subscription.
If a Subscription is found, it is updated with the latest details.
The expiry date of the subscription is evaluated and, if it is not expired, the User in Firebase is updated and the flag hasActiveSubscription is set accordingly. [...]
This has been working exceptionally well and robust for quite some time.
As far as I can see the developerPayload, which could be used to pass on, e.g. the UserID, to determine who the subscription belongs to, is deprecated. (Source)
Do you think there is an easier way of doing this, possibly
only using Google Play Developer notifications?
I am receiving a notification at every step a subscription changes and I am simply updating my Subscription and hasActiveSubscription flag based on the expiry date. This is working well because I receive a notification at the moment the subscription expires (notification type SUBSCRIPTION_EXPIRED) and at any point the subscription gets extended, for example. (Source)
Is there anything missing in that validation logic or any potential risk?
These two questions so far are only to ensure I am not missing something essential. Again, from my experience this is working quite well.
All that is left for my app (based on Flutter, by the way) to be released on iOS is to implement the validation logic for iOS.
One thing that has made the google validation logic rather easy, is that there is the googleapis library, which essentially is giving me the model classes for all responses, such as the notifications or the subscription details. I have been unable to find something similar for Apple yet and I am not sure there is.
Is there any (official) library that is providing me with similar features as googleapis for Node.js?
For new subscriptions I am currently querying the verifyReceipt endpoint, which seems to be working well. However, Apple does not seem to say anywhere which fields need to be validated exactly, in order to provide users with access within the app. I am following the same logic, meaning: If I do receive a valid receipt from the endpoint and it is not expired, I grant access.
Is that logic sufficient for new subscriptions or am I missing something?
For Google so far I simply stored the subscription details that I received via querying the api, including the UserID and token. This is done mainly for laziness and because the document structure received is rather simple. The Apple responses are much more complex, so I am quite unsure about what to store (and poorly documented, if you ask me), so I am wondering:
Which details do I actually need, for both Google and Apple, especially if I rely on notifications for updating the subscription?
Regarding updates to the subscriptions, I am wondering how to work with server-to-server notifications from Apple.
When exactly are they being send and can I implement the same logic as described above for Android?
As I can't seem to find a good documentation or tutorial for this part:
Do you possibly know any good tutorials for these notifications?
Thank you very much for your support,
Matthias
It has been a while since i asked these questions and while technically the questions have not been answered, I would still like to share my solution with everyone.
The solution I have gone for is simply implementing RevenueCat, who focus on managing in app subscriptions for you, so that there is no need to worry about all those questions anymore.
I am building a webapp which requires users to regularly top up their account. To allow for this I am exploring the google wallet inapp payments api and have got this working fine. However, I would like users to be given the option to auto-top up when their account balance becomes low. I have looked at the subscription documentation but cannot see whether this is possible or not - it seems you can only have a subscription which draws money at regular intervals.
Is there a way to have a user pre-authorise this kind of transaction, and if so could you please point me to any documentation that would allow for this?
I don't believe so. The subscription feature is probably your best bet and should (unless I'm missing something) get you to the "same place".
A "pre-authorization" somewhat says, you'll come back at some later time to charge (aka "capture") the pre-auth. There is no API command that does that (capture/charge) in Wallet for Digital Goods. The process is immediate...
There (is) used to be one in the Google Checkout API where you are given 7 calendar days to charge a pre-auth. However, this product will be retired in November.
We are prepping for the release of a large web application that has been in development for the past year. We are about to start the process of integrating ActiveMerchant to handle recurring subscription fees for the service.
I am looking for any advice regarding best practices considering our requirements (listed below) and any additional heads-up for common pitfalls or specific issues I should be giving special consideration. The payment gateway we will be using is PaymentExpress as it's one of the few supported gateways that has recurring billing and doesn't have any special conditions for companies operating outside of the USA. The business behind this application is based out of the UK.
Users of the application create an account with a sub-domain where they can access and customise the application and their data. Below are some of the requirements/features that might have an effect on how billing works:
All users get a 30 day trial
There are different plans, including a free one
Higher priced plans have larger limits on the amount of data (e.g. users, projects, etc) they can have in their account
Billing period will be monthly, beginning after trial
There will be discounts/coupon codes to get a percentage off the normal price for a year on plans, etc.
Plan pricing will change as features are added
Specific hurdles I can foresee will be things including the following:
How to handle downgrading when they violate the plan limits for lower level plans.
Behaviour when credit cards expire or payments don't go through (a read-only mode enforced, perhaps)
When plan pricing changes, we want to honour previous prices for existing users for a time period (such as 6 months), then start charging higher rates. If the plan price decreases, it will take effect immediately.
Other advice that would be helpful would be anything regarding flow of the application. How should billing forms be presented to the user? When should credit card information be required? How should invoices be sent, stored, and accessible?
I should disclose that we plan to base a lot of the code base off SaaSy. SaaSy is designed to be used as a separate Rails app that handles all the signup and account management side of things. However, this doesn't work for us since we never planned for this from the beginning and it would be a tedious process to adapt our application to work like that. Consequently, we'll be pulling code and ideas from SaaSy and merging them into our app, a considerably less tedious task.
One thing I wanted to add: keep in mind you don't need to use the recurring billing feature that is built into the gateway. In general these systems are legacy and very difficult to deal with, we get spoiled in the rails world.
You get a lot more flexibility just using them for one purpose (to bill a credit card, and perhaps also store credit cards for PCI compliance). Then roll your own recurring billing in your rails app with a cron job, a date field for when they are paid through, and amount each person is paying (in case they used a coupon) etc.
One small example: sometimes people will cancel a monthly subscription in the middle of the month. They want to make sure they don't forget to cancel before the next payment. Most gateway recurring billing that I've seen will instantly terminate the account (or send you a message indicating this). In reality, the user has paid through the end of the month and should be given 2 more weeks of access. You can do this if you have rolled your own recurring billing in rails, but not if you are using the gateway recurring billing. Just a small example.
RailsKits has a Software as a Service kit that should do what you need. It has built-in support for free trials, upgrading, downgrading, plan limits, etc., and it supports PaymentExpress (and some others).
I've researched it a bit for a project I'm doing, but I haven't purchased it yet so I can't vouch for it. However, I have seen a few blog posts praising this kit.
While the RailsKit is relatively inexpensive when compared what it would cost you to implement all of its features yourself, there are a couple open source versions out there that aim to accomplish the same thing. The one I remember off the top of my head is called Freemium.
EDIT: I forgot to mention that Ryan Bates said in his most recent Railscast that his next episode or two will deal with recurring billing, so keep an eye out for that. He usually does one episode per week, and the five he's done since December 22 all cover handling payments of different types.
Peepcode has a PDF for sale(70 pages) that details various aspects of payment processing and industry practices for this. It may be worth checking out:
http://peepcode.com/products/activemerchant-pdf
I'm also in the middle of setting up a subscription based website and these are our current requirements. They may help you regarding best practice:
Users will be able to choose one of
the subscription plans.
Users will be required to enter their
credit card details to sign up to
their chosen plan.
All major credit and debit cards must
be accepted including Maestro and
American Express.
Each plan will have a 30-day free
trial so users' credit cards should
only be charged after the 30-day
period expires. However, the validity
of credits cards should be checked at
the time of sign up.
Users will be emailed a few days
before their credit card is charged
to notify them that they will be
charged soon unless they cancel their
account. If they cancel their account
within their 30 day free trial, their
credit card should not be charged.
After any free trial period, users
will be charged in advance for their
use of the system - ie they will
pre-pay.
Users will be charged automatically
every month for their chosen plan.
Each month, users will be sent an
email a few days in advance to notify
them that they will be charged. Once
payment has been made, users will be
emailed an invoice showing that their
payment has been received.
Users will be able to upgrade or
downgrade their accounts at any time.
When users upgrade/downgrade, their
next subscription charge will be at
the new rate. Users will only be able
to downgrade their accounts to a plan
that can handle their data. For
example, if they currently have 10
active projects they can't downgrade
to the Basic plan because the Basic
plan only allows 5 projects. They
will have to delete or archive 5
projects before you they can
downgrade to Basic.
Users will be able to log in to their
account and change or update their
credit card details.
Users will be able to cancel their
account at any time. There will be no
further subscription charges after a
user has canceled their account.
However, users will not be refunded
for part of the month they have
already paid for.
All parts of the payment system must
be 100% PCI DSS compliant; including
any 3rd party systems.
The payment system must support
automated notification and retry of
failed subscription renewals.
The payment system must support
discount vouchers with expiry dates.
Credit card details must not be
processed by or stored on our servers
they should always be processed/stored by our 3rd party
payment processing partner. We do not
want responsibility for securing
these details and complying with
legal rules and regulations.
Users will be able to log into their
accounts and see a full billing
history including dates and amounts
paid. We will also need to be
able to log in to a system to see
customer payment plans and payment
history. This will be essential for
customer service.
We've also been looking at http://chargify.com/ which looks like it could save a lot of coding time.