Its been my two months using GCP cloud sql. 1st month I got a invoice of INR1200. This month till date i have an estimated charge is INR 206. Though I have International SBI debit card, not able to connect because its saying Your card does not support automatic recurring payments.
user8104070
First solution to your problem: Use a SBI Credit Card or any Other Credit Card. Debit Card is just an ad-hoc Solution to use on your GCP account.
Secondly, this is not the right platform for asking this types of questions. Next time try contacting the Customer Support or read Google Official Documentation for your problems.
Anyway, Happy to help!
Related
I'm planning for my new application, and its contain payment method, after research on google, im found google pay will be better one.
but how google pay will deducts the amount from the user and tranfer it to my bank number?
is their any proccess or third part ?
Best Regards and thanks.
Google Pay does not actually process the payment. It facilitates it by securely transmitting the user's selected payment method to a payment processor.
A list of supported payment processors can be found at https://developers.google.com/pay/api/#participating-processors.
Instructions on how to integrate with the relevant payment processors can be found by following the processor links.
I want to add some unit tests for our billing system which is using braintree but I don't know how to change the subscription period from 1 month (minimum in braintree for now) to 1 day. I cannot wait 1 month to execute my test. is there any solution to do that?
I recently asked Braintree support a similar question and here is the advice I was given:-
The sandbox environment is setup to mimic the production environment exactly. Unfortunately, this leaves us at the mercy of real time as well. However you can definitely test the subscription_charged_unsuccessfully and subscription_went_past_due webhooks in the sandbox by creating a past due subscription using the steps below:
Create a plan with a 1 day trial and $2000 price (a test amount that will automatically simulate a decline)
Create a customer with a credit card
Create a new subscription using the plan and customer
The first charge attempt will be after 1 day (when the trial expires) and will fail
The automatic retries will be at +10 and +20 days of the subscription going past due – this timeline can be changed by updating the recurring billing retry logic in your Control Panel
You could also test the subscription_charged_successfully webhook using the same basic principles – simply create a plan with a 1 day trial and a price less than $2000.
I hope that helps.
I work at Braintree. Feel free to reach out to support#braintreepayments.com with any further questions.
You can't modify the subscription billing period to shorter then a month. Sandbox is designed to mimic production for end-to-end testing and since Braintree doesn't offer subscription billing in smaller increments then a month we have decided to not offer a shorter billing period in sandbox.
Is it possible to use PayPal's preapproved payments api for the following scenario:
Online marketplace where users buy fixed amounts of credits.
They spend the credits on items/services in the marketplace.
We detect when the credits run out and based on the billing agreement automatically charge them to renew the amount of credits.
I have spent quite a while looking around for an answer to this but cannot find my specific problem.
Any help very much appreciated! Thanks.
Yes this is definitely possible. I would write a cron job that periodically checks current credits against their billing agreement. If there is a match, then make a pay request to paypal. Sorry I cannot provide code examples without more knowledge of how your site is structured.
I'm looking at the possibility of setting up limited acceptance of debit cards online. However, as I research, I see that there are huge differences in the interchange rate between debit cards that are regulated under the recent Durbin amendment and those that are exempt. Depending on my merchant account fee structure, this could give us wildly different costs based on how the transaction gets categorized.
If I'm using authorize.net as the gateway, is it possible to use their API to determine the categorization of the card on the interchange with just an authorize transaction? (and thus accept only cards that I know can be processed cheaply, and give an "i'm sorry" message to everyone else). Is there any other way to identify them without actually making the charge on the card?
Unfortunately there isn't. The rates used to process a transaction are determined at transaction time and are not available via any API. You can only find out what rate was charged by viewing the reporting offered by the merchant account provider.
I'm building a marketplace application:
The customer pays the seller on the marketplace
The marketplace takes a cut of the payment
I would have a payment processing system with the following features
The cut and the 100%-cut are sent directly to the marketplace and seller accounts (ie, I don't want to have 100% on the marketplace account and then to forward the 100%-cut to the seller)
I would love to have a UI as much integrated with the marketplace website as possible. This implies that the customer in the worst case has to put only name, surname and credit card number on the payment processor interface (the ideal would be a payment interface totally integrated with our website)
I don't want to force the customer to register to any third party service
It should work nicely with Ruby on Rails
It should work for non US-based companies and should support multicurrency payments
What are the options out there?
Thanks.
I'd recommend you look at our product Balanced. It's built to solve exactly this problem so I think it's a good match.
At a high level payments in are done via credit card like a normal payment processor, funds are deposited into an escrow account which is a sum of all funds collected - all funds disbursed. When you're ready to push funds out you can currently pay out via next-day ACH (US only) but we're building out international support which sounds like it would be useful for you.
I believe it matches your other requirements:
there is no requirement to send users offsite, they do require accounts but you can create and edit them via the API.
Balanced has an excellent ruby gem
You can split up the payment, taking a cut from the proceeds as profit
Balanced provides you with a merchant dashboard for you and your customers to get a head start but you can build the exact same thing via API access.
One area where it's not going to meet your requirements is multi-currency charges. Currently you'll need to charge in USD and convert.
Check out https://github.com/drhenner/ror_ecommerce It doesn't have all the features you want but will give you a big head start.
Basically active merchant will connect to most gateways. You need to add the custom code. Look at the video for more help http://ror-e.com/info/videos/1