Is there any option to pass the card type (e.g. VISA,DISCOVER etc ) while create new Credit Card request is make in Braintree. And any validation if no type is pass to the request. I am unable to see any validation while no type is pass with the request.
Related
I have an integration test connected to Stripe (test mode) and I would like to test the complete flow, i.e. creating payment-intent and handling the webhook of succeeded event. The first part is pretty straightward. Now for the second part, Obviously I can't do actual flow on the Element widget. So I tried to manually confirm the payment intent (as part of the test code) with the following call:
fun confirmPaymentIntent(pi: PaymentIntent): PaymentIntent {
val params = PaymentIntentConfirmParams.builder()
.addExpand("latest_charge")
.setPaymentMethod("pm_card_visa") // Don't know what's the correct value!
.setReturnUrl("https://example.com/return")
.build()
return pi.confirm(params)
}
And it works fine, I receive the "payment intent succeeded" event in the webhook. Now the problem is that the real payment flow would contain billing details. So I tried the following:
.setPaymentMethodData(
PaymentIntentConfirmParams.PaymentMethodData.builder()
.setBillingDetails(
BillingDetails.builder()
.setAddress(BillingDetails.Address.builder().setCountry("US").build())
.setName("My Customer")
.setEmail("customer#example.com")
.build()
)
.build()
)
But when I run the code, it's complaining about missing type in the payment method data. Type enum doesn't have card and I have no idea what is the correct value.
In my case, the application supports only cards and it doesn't care about the card details in any way (so anything works, like fake card, token, etc, as long as I get the payment intent event with the name and email info in the webhook.)
First, is there any better way to do this? Second, if not, then how can I manually confirm a payment intent in the test to be able to verify webhook call? Thanks.
You can trigger the payment_intent.succeeded event directly via Stripe CLI. If that still doesn't give you the information to test, you would want to build an end-to-end frontend confirmation flow using PaymentElement. It's not that complicated.
I'm trying to create a customer in Stripe using Excel VBA and the Stripe API. I'm able to do this successfully, however I've hit a snag.
When I send the following URL to the API, I am successfully creating a customer with the following parameters (auto_advance, collection_method, customer) set.
b_url + "/v1/invoices?auto_advance=false;collection_method=charge_automatically;customer=" + customerid
However, I am struggling on the syntax required in my URL when attempting to send values to a parameter with child attributes. Stripe customer object has a parameter called "custom_fields" that I would like to populate. The param requires a custom_fields.name and custom_fields.value.
How do I send parameters with a "dot"?
So it turns out the URL needs to be formatted as an array value to pass these. So sending
;custom_fields[0][name]=Provider;custom_fields[0][value]=TestName
worked great.
my project is to have a chatbot that can sell electronic device like resistor, diode and so on.
There are many type of resistor and diode
I have my intents in dialogflow so when user choose one item I need to store it into php session variable so when user have finished so I need to restore that items in session variable but it doesnt work
Recieve dialogflow intent that is called "tomar_cantidad"
if (intent_recibido("tomar_cantidad")) {
$modelo = obtener_variables3('modelo');
$cantidad = obtener_variables2('cantidad');
//enviar_texto(print_r($cantidad));
$datos_usuario = array('modelo'=>$modelo,'cantidad'=>$cantidad);
$_SESSION['datos_usuario'][]= $datos_usuario;
enviar_texto(print_r($_SESSION['datos_usuario']));
}
enviar_texto is a method to send information to dialogflow(that is for testing purposes).
I recieve session variable but only store the last item that user choose not all items
The issue is that the PHP $_SESSION variable is tied to an HTTP session, which is usually implemented with an HTTP cookie. But Dialogflow doesn't manage HTTP cookies when it sends messages to a webhook, so each fulfillment call is a new session each time.
You have a few ways you can approach this:
Get the Dialogflow session ID and store the information against this ID
Store any values you want to store between turns in the conversation as a parameter in an Output Context. You should set the lifespan for the Context to a large number, 99 is typical, or re-set this as the Output Context each time. Then, you can read the parameter in the named Context when you need the information.
I would like my Actions on Google agent to store and retrieve certain pieces of information across invocations - like a cookie. How do I do this?
You have a lot of options on how you want to do this, depending on exactly what you're trying to do. It isn't exactly like a web cookie, although there are similarities.
If you want the equivalent of a session cookie, information that is retained during a single conversation, then your options are
Using the Session ID provided as part of the information sent to you on each invocation and tracking this in your fulfillment.
Storing information you want retained using a Dialogflow context
If you are using the actions-on-google JavaScript library, storing this in the app.data object created for you.
If you want the equivalent of a long-lasting cookie to retain information between conversations then your options are
Using the anonymous User ID provided as part of the information sent to you on each invocation and tracking this in your fulfillment.
If you are using the actions-on-google javascript library, storing this in the app.userStorage object created for you.
Storing it as part of the string in the JSON response under data.google.userStorage.
Some more information about each of these
Session ID
A different Session ID is created for each conversation you have. You can get this Session ID by examining the JSON sent to your webhook in the sessionId parameter.
You can then look this up in a data store of some sort that you manage.
Dialogflow context
Contexts are powerful tools that are available with Dialogflow. You return a context as part of your fulfillment webhook and indicate the name of the context, its lifetime (how many more rounds of the conversation it will be passed back to your webhook), and any parameters associated with the context (string key/value pairs).
Contexts are especially useful in helping determine what intents may be called. You can indicate what contexts must be active for an Intent to be recognized by Dialogflow.
If you're using the actions-on-google node.js library, you can set a context using something like this:
var contextParameters = {
foo: "Something foothy",
bar: "Your local bar."
};
app.setContext( "remember_this", 5, contextParameters );
You need to do this before you call app.ask() or app.tell().
Or you can do the equivalent in the JSON as part of the contextOut block of the response
"contextOut": [
{
"name": "remember_this",
"lifespan": 5,
"parameters": {
"foo": "Something foothy",
"bar": "Your local bar."
}
}
]
The next time your webhook is called, you can fetch this context either by looking at the result.contexts array or by using the app.getContext() or app.getContextArgument() methods in the library.
Using app.data
If you're using the library, Google has done some of the work for you. The app.data object is created for you. Any values you set in the object are available for the lifetime of the session - you just read them in later calls to your webhook.
(Under the covers, Google uses a context for this, so there is no magic. The two work together and you're free to do both.)
Anonymous UserID
When a user first uses your action, a user ID is generated. This ID doesn't give you access to any specific information about them, and isn't used for any other action, but every time you see it, you can be assured that it was the same user that used it on a previous occurrence. Just like a cookie, however, the user can reset it and a new ID will be generated for them for your action.
You get this from the JSON at originalRequest.user.userId or by using app.getUser().userId. Once you have it, you'd use a data store of some sort to store and retrieve information about this user.
Using app.userStorage
Similar to app.data, there is also an app.userStorage object that is created for you for each user. Any changes you make to this object are saved in between conversations you have with this user.
Unlike app.data, however, this doesn't get stored in a context. It has its own storage method. Which leads to...
Storing it in JSON
If you're not using the actions-on-google library, you still have access to userStorage through the response and request JSON directly. You need to store this as a string, but if you need to store a more complex object, a common method is to stringify it as JSON.
You'll store this value under data.google.userStorage in the response and can retrieve it under originalRequest.data.user.userStorage in the request your webhook receives.
You can save the information in Context with a key value parameter.
SAVING VALUES IN CONTEXT :
agent.set.Context({
name:'context-name',
lifespan: 5,
parameters:{
'parameter-name':'parameter-value'
}
});
GETTING VALUES FROM CONTEXT
agent.getContext('context-name');
For more Details : https://dialogflow.com/docs/contexts/contexts-fulfillment
You could also use a Google Cloud database like BigQuery or Firestore
Sounds like you may want to checkout out Account Linking: https://developers.google.com/actions/identity/account-linking. With account linking you can collect end-user information which you exchange with Google by providing a unique key. This unique key becomes part of every request you receive from Google, so when you get that unique key you lookup the information you collected from the end-user. In your case, you would store credentials or whatever key is required to access the end-user information. After the initial linking, any new data you obtain could be stored along with the original information collected, based on the unique key obtained during account linking.
For this purpose, i just did a node module just for that, in external json file from api call, i need to store and add additional informations to retrieve later. I thing that you can do a lot with this module, Store object, array, json, value, Navigation history?, back to previous page.
It work like localStorage or Cookies.
There's no limit, you can create multiple storage by name (key) an value. It's new and i'm testing it for bugs right now on my own project.
Test on Runkit
On npm
vStorage = require('virtual-storage');
vStorage.set('name', '{title:'Title 1', description:'Descriptions 1'}')
let getStorage_name = vStorage.get('name');
console.log(getStorage_name.title);
vStorage.get('name')
I want to use Stripe to charge cards recurrently every 30 days with amounts that oscilate.
From the docs I got that if there is a possibility that the card requires 3DS we should use Sources so I switched to sources ;)
From the source object stripe.js retrieves I look at three_d_secure param to decide whether to create a source object that requires 3DS or a normal card charging.
The flow:
With JS I get the source object that has three_d_secure set to either optional or required.
When it's set to optional after I retrieve the source with: source = Stripe::Source.retrieve(source_id) it looks like this:
"status": "chargeable",
"type": "card",
"usage": "reusable",
"card":{"exp_month":12,"exp_year":2032,"brand":"Visa",...
I attach it to a customer and charge it. I guess usage: reusable means that I can charge the card again later...
When three_d_secure=='required' I create a new source calling this:
source = Stripe::Source.create({
amount: amount,
currency: currency,
type: 'three_d_secure',
three_d_secure: {
card: source_id, #src_xcvxcvxcvc
},
redirect: {
return_url: return_url
},
})
I redirect the user to the URL Stripe provides, user enters his 3DS PIN and gets back to my return_url. When Stripe redirects the user back to my return_url I retrieve the source again and get something like this:
"status": "chargeable",
"type": "three_d_secure",
"usage": "single_use",
"three_d_secure": {"card":"src_1B1JzQHopXUl9h9Iwk05JV1z","authenticated":true,"customer":null}
I would expect that after passing the 3DS the source becomes reusable and chargeable until the date of expiry or so :|
My questions are:
1 Why is the 3DS source single_use? Is this like this only in sanbox environment or with the card I am using to test?
2 Can a 3DS protected card be charged again at all?
3 What's the correct approach to attach to customer sources (3DS or normal) that can be charged again and again?
Thank you!
Because it is a source payment token, not a source card token. It expires on a due date or when is consumed. You can use reusable token to create single_use tokens. reusable one represents a card source token
Yes if a 3ds is optional or not_supported, no if required. If required then every payement needs to fulfill a 3ds.
Steps:
Create an src_card_token for a card or use saved one (reusable)
Create an customer object with an src from src_card_token
Create an src_payment_token for a customer using one of his saved cards (as token)
fullfil a 3ds redirect process if required.
create a charge