Stripe to Stripe Transfer - stripe-connect

I want to use Stripe Connect in my iOS project. My requirement is to transfer an amount from my platform account to a connected account. This is possible with 'Special case transfers' but it has some limitations. Due to this, I'm planning to accept payment on my one connected account and will then transfer it on to another. It is possible to transfer an amount from one connected account to another?

It all depends on the amount you have to transfer. If you only need to wire less than 10% of your overall net volume, you can use special cases transfer. I am actually using it on my platform like this :
Stripe::Transfer.create(
amount: params[:amount].to_i,
currency: 'eur',
destination: params[:stripe_id]
)
Anyway, you cannot transfer funds from a connected account to another. I already faced this situation, and I contacted Stripe support who confirmed this.

Stripe connect plateform provide such things
at first deducted amount submitted to stripe admin account than admin account to respective bank account.
doc : https://stripe.com/docs/api/transfers
stripe.transfers.create(
{
amount: 400,
currency: 'gbp',
destination: account_id,
transfer_group: 'ORDER_95'
},
function(err, transfer) {
}
);

Related

Google Play Developer API purchases.subscriptions doesn't return emailAddress field

I'm integrating with Google Play Developer API (https://developers.google.com/android-publisher). To be more specific I'm trying to get informations about a specific subscription (https://developers.google.com/android-publisher/api-ref/rest/v3/purchases.subscriptions/get).
Well I'm already getting informations about a subscription with the subscriptionId and purchaseToken. The problem is that some fields are not being returned in response. One of these field is emailAddress that importante for my usage context. I'm getting a response like the one shown below.
{
"startTimeMillis": "1631112305355",
"expiryTimeMillis": "1638981894973",
"autoRenewing": true,
"priceCurrencyCode": "BRL",
"priceAmountMicros": "39990000",
"countryCode": "BR",
"developerPayload": "",
"paymentState": 1,
"orderId": "GPA.9999-5849-9341-89139",
"acknowledgementState": 1,
"kind": "androidpublisher#subscriptionPurchase"
}
From the docs about emailAddress we have The email address of the user when the subscription was purchased. Only present for purchases made with 'Subscribe with Google'.
But what is Subscribe with Google? Isn't Google Play Billing in this category? My purchases are made on an Android mobile app with Play Billing.
Thanks any help.
Subscribe with Google is a completely different thing that Google offers or at least used to offer, these are not normal subscriptions, for normal subs you do not get the users email.
Subscribe with Google lets you buy a subscription, using your Google
account, on participating news sites. Select the publisher offer you’d
like to buy, click “Subscribe,” and you’re done. You’ll automatically
be signed in to the site, and you can pay–securely and privately—with
any credit card you’ve used with Google in the past.
https://blog.google/outreach-initiatives/google-news-initiative/introducing-subscribe-google/

How to implement auto renew subscription in app billing google play

I'm researching method to implement auto renew subscription in app billing with google play. I read https://developer.android.com/google/play/billing/billing_subscriptions.html and see
Billing continues indefinitely at the interval and price specified for the subscription. At each subscription renewal, Google Play charges the user account automatically, then notifies the user of the charges afterward by email. For monthly and annual subscriptions, billing cycles will always match subscription cycles, based on the purchase date. (Seasonal subscriptions are charged annually, on the first day of the season.)
When the subscription payment is approved, Google Play provides a purchase token back to the purchasing app through the In-app Billing API. Your apps can store the token locally or pass it to your backend servers, which can then use it to validate or cancel the subscription remotely using the Google Play Developer API.
So have any method to my server know when user's subscription was renewed? Instead of google play send new bill subscription to android app after that android app send this new bill to my server just for validate.
Can google play send a notify to my server when user's subscription renewed such as notify the user by email ? I want to google play send me a notify that user's subscription was renewed automatically so that my backend will update expire their subscription in app increase. Don't need android app have to check bill each time user open store to check have new bill from goole play charge automation or not. Do it implement?
My workfollow
Google charge a new cycle subscription and notify to my server { body such as bundId, bill, product_id or subscription package name, expire date...), also sent mail to user about their subscription automation renewed.
My server determine change subscription of the user and validate in app purchase by google play api and change expire package subscription in your app if validate is valid.
Store newest bill in my db
Is that possible?
[Update] Recommend from goolge play api doc
Recommendation: Include business logic in your app to notify your
backend servers of subscription purchases, tokens, and any billing
errors that may occur. Your backend servers can use the server-side
API to query and update your records and follow up with customers
directly, if needed.
How to implement recommend from google api, any doc or tutorials ?
I have currently exactly the same problem. The concept of Google is not well-conceived. There is a possibility to notify your backend server about financial transactions (see here), but I would not recommend this. You rely your business transactions on a lot of Google services and your server uptime. If anything goes wrong or is down or something, you will not be informed and your backend business logic does not work anymore.
This recommendation of Google you mentioned sucks as well. What happens if there is an auto-renawal (which delivers a new purchaseToken to your app) and the user never opens your app. Then the new subscription data will never be transferred to your server. And if you never got a new token, how can you check, if the user is still a subscriber, since this limited Google Play Developer API stupidly needs a purchaseToken as parameter (see here) that you never get as long as the user does not open your app at least once after an auto-renewal (to submit it to your server).
I think about implementing this in this way:
1.) I continuously check the purchase records by cron job. A purchase record is a database entry which contains all data from the initial subscription (orderId, purchaseToken, and so on, all that is needed for the security validation process on the server). Every purchase record is connected to a user's account (some UserID) in my backend system. As long as the autoRenewing attribute of the purchaseRecord is not false, the subscription is valid. Even if the expiryTimeMillis is exceeded, this one user could still have a valid subscription, because of the use case I described above: Subscription will be auto-renewed by Google, but the user never opens the app, so no transfer token is sent to your server and you are still not informed about the subscription update.
2.) If the use cancels his subscription any when, the autoRenewing would be false at any time. That means that the subscription will indeed end at the expiryTimeMillis.
3.) When the user opens your app and transfers the new purchaseToken to your backend, you will get a new purchase record which is again connected to the user account with his User ID. The user will probably have 2 purchase records now. The old one and the new one. If so, you could delete the old one, and the same process repeats with the new purchase record at step 1.
I didn't have implemented the concept so far, so I don't know if this really works like this. Maybe this could work in a different manner, but maybe it's a step into the right direction.
I don't think, relying upon daily basis cronjob is a feasible way to go about this problem, It is messy and you have to also consider the case when your application is handling too many requests, you have a limit of transactions that made using android developer's api. The better way to implement it would be to use google's recommendation. Which stats:
...
Note: Due to quota restrictions, it is not recommended to check state by polling the Google Play Developer API at regular intervals instead of leveraging Real-time developer notifications.
...
Here, You can follow the following url
How to get expiry date for Subscription with client side in Android? and to implement the auto-renewal subscription.

can uberRUSH drivers be given instructions

Is it possible with UberRUSH to give drivers a simple errand before delivery such as go to shop 'x' and buy 'y', then deliver it to address 'z'? Provided that the payment for 'y' is provided as part of the payment.
No, UberRush provides on-demand delivery only. If the task is a simple note for how to pickup you can specify - talk to reception, go to floor x, but not actual tasks..

Yodlee soap service How to get accountNumber and routingNumber from getItemSummaries method

I'm integrating yodlee soap service to loan management system. To perform validation I need to get accountNumber and routingNumber from the bank account. On my bank account web site I can see account number but yodlee masks out part of account numbers by 'x' symbol and returns something like xxxx7-50 in getItemSummaries response. Also some accounts have empty routing number.
Is that some king of security limitation or it can be due to fact that I'm currently using test yodlee account?
Is there way to get bank routing number and original bank account number without masking by using soap yodlee service?
Thanks.
This is because of security limitation of the Aggregation product.If you wish to have unmasked account number then you will have to go through some tests from Yodlee's security team and then Yodlee can customize the API to send you unmasked account number. For this you need to get in touch with sales representative.
Also if you are building the solution for US market then you can try out the IAV data service APIs , if you are interested in Account number and routing number. As IAV is the main product for verification of account.

How come Appstore gets to store CVV2? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
How Appstore gets to skit round this restriction? Can CVV2 details be kept locally on an iOS device and still be in PCI compliance? Encrypt the CVV2 details locally, and only user has the key? While the rest of the credit card details like PAN are stored on server side?
SHORT ANSWER:
Your issuing bank doesn't require security code validation with every transaction.
LONG ANSWER:
Card security codes and magnetic stripe data are not permitted to be stored by PCI DSS. Furthermore, VISA (and possibly other networks) strictly forbid their storage:
http://usa.visa.com/merchants/risk_management/cisp_payment_applications.html
Merchants storing this data can be hammered with hefty fines and dropped by processors. This happened to a client of mine.
Apple's e-commerce system asks for the security code when an account is created or whenever a new device accesses an existing account. In both instances, their platform initiates a zero-dollar transaction with the processing network to verify the customers' identity (username + password + security code):
https://discussions.apple.com/thread/2594628?start=0&tstart=0
Some issuing banks require security codes to be used with each transaction. In those cases, the iTunes store will prompt you for the code.
xixonia is correct that personal data is tokenized within Apple's infrastructure. Most of their servers never touch secure data, as all credentials and financial data is passed encrypted to an inner network of highly protected and monitored systems.
In addition, large retailers like Apple and Amazon use third-party fraud detection and prevention technologies that look for patterns of abuse.
"It is permissible for issuers and companies that support issuing
services to store sensitive authentication data if there is a business
justification and the data is stored securely"
Easier purchasing and subsequent transactions are NOT business justification.
A pertinent use case would be batch transactions. During purchase the card is authorized to confirm the card is active and the funds are available. The issuing bank typically encumbers, but does not withdraw, the transaction amount from the cardholder's account. During a subsequent capture transaction, the merchant settles with the processor and the funds are transferred. This might happen because:
The issuing bank requires it (e.g., voice authorization).
The payment network requires it (e.g., American Express used to).
The merchant does not know the full transaction amount (e.g., restaurant tip).
The merchant does not have persistent connection to the payment network (e.g., mobile operator).
Going this route triggers MUCH higher scrutiny under PCI DSS. Merchants who use third party checkout systems like Google Checkout and PayPal get minimal treatment (SAQ A). Merchants who store ANY cardholder data have the heavy burden of SAQ D.
The compensating controls for holding security codes & magnetic stripe data are even more strict:
Data must be stored using best practices (randomized salt + strong encryption cipher + restricted keys + mandatory access controls + audited access).
Data must be automatically removed after a set grace period (typically a day or two).
Data must be securely overwritten and on a medium that allows it (most solid state drives' wear leveling mechanisms prevent this).