I'm trying to find a good approach to using stripe with react-native. Preferably one that doesn't involve sending credit card details to my own backend or storing my stripe private key in the application. Any ideas welcome! thanks
I have not implemented this in React Native personally yet. In the app I am working on this will be ported over in the next few days but here is how we do it in the current app without any dependency on third party libraries and how we will implement in React Native as well. This is obviously just a concept that can be used anywhere you can make a HTTP call.
Make a POST call to https://api.stripe.com/v1/tokens with a 'Authorization' header with the value Bearer {PUBLISHABLE_AUTH_TOKEN}. In the body (x-www-form-urlencoded) put:
card[name]={NAME_ON_CARD}&card[number]={CARD_NUMBER}&card[exp_month]={CARD_EXP_MONTH}&card[exp_year]={CARD_EXP_YEAR}&card[cvc]={CARD_CVC}
The response will be a JSON object that contains (among other things) an id field. This id field is what you will reference the card when making transactions so this ID needs sent to your server and stored. This ID can be stored without worry of PCI compliance.
More Info: https://stripe.com/docs/api#tokens
I recommend: https://github.com/tipsi/tipsi-stripe
I was able to successfully connect React Native and Stripe to create a customer and add a card and save the tokens to my back end.
I'm still not sure, but what We want to achieve is simple.
With react, we were able to achieve this by calling stripe from the front end for card information. However, React Native does not have its own code.
So we need to get everything we need from by ourself Like this
curl https://api.stripe.com/v1/tokens \
-u sk_test_IjzBJWterND0tgdSyEIhDmgS00ODHLjw1a: \
-d "card[number]"=4242424242424242 \
-d "card[exp_month]"=7 \
-d "card[exp_year]"=2021 \
-d "card[cvc]"=314
and you will get
% curl https://api.stripe.com/v1/tokens \
-u sk_test_IjzBJWterND0tgdSyEIhDmgS00ODHLjw1a: \
-d "card[number]"=4242424242424242 \
-d "card[exp_month]"=7 \
-d "card[exp_year]"=2021 \
-d "card[cvc]"=314
{
"id": "tok_1H2Vt9AxSyQJWoao8qhjHDuh",
"object": "token",
"card": {
"id": "card_1H2Vt9AxSyQJWoao26em4Dps",
"object": "card",
"address_city": null,
"address_country": null,
"address_line1": null,
"address_line1_check": null,
"address_line2": null,
"address_state": null,
"address_zip": null,
"address_zip_check": null,
"brand": "Visa",
"country": "US",
"cvc_check": "unchecked",
"dynamic_last4": null,
"exp_month": 7,
"exp_year": 2021,
"fingerprint": "IS61beTzZemIdd8p",
"funding": "credit",
"last4": "4242",
"metadata": {
},
"name": null,
"tokenization_method": null
},
"client_ip": "153.218.66.247",
"created": 1594186331,
"livemode": false,
"type": "card",
"used": false
}
You can use the tok_ on the card to implement backend charges as usual.
I ran into issues doing this with existing libraries, so I wrote a better one. react-native-stripe allows you to collect credit card information, validate it using Stripe, and exchange it for a Stripe token, all using native code. Currently iOS only.
Related
There is a transaction on RSK Testnet,
0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390,
where tx.to is the zero address,
and tx.data is also zero.
However, it shows that this was a deployment transaction,
and that a contract was created at this address.
It seems like (instead of a contract deployment)
this should be a "burn" transaction,
where RBTC is sent to the zero address.
How is this possible, and how does this work?
Additional detail, eth_getTransactionByHash:
$ curl https://public-node.testnet.rsk.co -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionByHash","params":["0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390"],"id":1}' | jq
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"hash": "0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390",
"nonce": "0xdbd",
"blockHash": "0x0ecc95ab88bb1d72e8d83d015e9e31e65230c3035809db4476a28e56d22ef11c",
"blockNumber": "0x12f7d9",
"transactionIndex": "0xe",
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"gas": "0x186a0",
"gasPrice": "0x3dfd242",
"value": "0x1558df2903f400",
"input": "0x",
"v": "0x61",
"r": "0x976033c43bed3a37cde8808bcf32930d396f3c035d8fe21246dd8ef9dbade200",
"s": "0x3777a1fa46829fe8fbb976b464ccccb3d2d2c255379bbf878efcbb5140351fcd"
}
}
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"value": "0x1558df2903f400",
"input": "0x",
Additional detail, eth_getTransactionByHash:
$ curl https://public-node.testnet.rsk.co -X POST -H "Content-Type: application/json" --data '{"jsonrpc":"2.0","method":"eth_getTransactionReceipt","params":["0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390"],"id":1}' | jq
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"transactionHash": "0xf3b1d43850523d45b4c84c5098ff0cf6bb74d1eb350b9574315433544f990390",
"transactionIndex": "0xe",
"blockHash": "0x0ecc95ab88bb1d72e8d83d015e9e31e65230c3035809db4476a28e56d22ef11c",
"blockNumber": "0x12f7d9",
"cumulativeGasUsed": "0xd1f15",
"gasUsed": "0xcf08",
"contractAddress": "0x3c9c7b9f43ad1ffe46beb4f58232157fb26f88c0",
"logs": [],
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"status": "0x1",
"logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}
}
Relevant parts
"contractAddress": "0x3c9c7b9f43ad1ffe46beb4f58232157fb26f88c0",
"logs": [],
"from": "0x1bb2b1beeda1fb25ee5da9cae6c0f12ced831128",
"to": null,
"status": "0x1",
A contract without code is simply an account that was created by CREATE or CREATE2,
but without specifying any data to put as initializer (which is the piece of code that when executed returns the code to install in the contract).
When this happens, an empty smart contract is deployed.
In RSK, contracts are identified internally when they have a "storage node root" in the trie. Every time a contract is deployed (with empty code or not), the storage root node is created in the RSK trie below the account node.
RSK internally does not identify contracts when they have code or not.
Note that this is a difference in the RSK consensus when compared to Ethereum consensus.
This consensus difference is reflected in
RSKj network node,
which is different from geth (Ethereum most used network node).
When RSK creates an account, it creates a small portion of the trie that stores the storage data (even if there is no data yet). RSK pre-creates a single node in the storage trie (a very compact one, storing a single byte). This dummy node has several purposes. One is to be able to easily compute the storage size, or the storage hash digest (both fields are embedded in the node).
When you call isContract() in the code, the RSK node looks for this "dummy" storage root node and returns true if it is present.
It does not check the existence of non-empty code.
Additional notes regarding smart contracts and isContract():
Currently isContract() is not called by consensus code except by the CODEHASH opcode, and CODEHASH returns the same result (KECCAK_256_OF_EMPTY_ARRAY) if the code is empty, and if isContract() returns false, so we may say that alternate definition of isContract() has no "visible" consequences from outside the node (i.e. by performing Web3-RPC calls). The RSK node behaves exactly as the Ethereum node.
However it was called by consensus code prior the CODEHASH opcode was fixed, as specified in RSKIP-169 "Rectify EXTCODEHASH implementation". Therefore there may have been visible consequences of isContract() in blocks before RSKIP-169 was activated.
I'm using wit ai for a bot and I think it's amazing. However, I must provide the customer with screens in my web app to train and manage the app. And here I found a big problem (or maybe I'm just lost). The documentation of the REST API is not enough to design a client that acts like the wit console (not even close). it's like a tutorial of what endpoints you can hit and an overview of the parameters, but no clean explanation of the structure of the response.
For example, there is no endpoint to get the insights edge. Also and most importantly, no clear documentation about the response structure when hitting the message endpoints (i.e. the structure the returned entities: are they prebuilt or not, and if they are, is the value a string or an object or array, and what the object might contain [e.g. datetime]). Also the problem of the deprecated guide and the new guide (the new guide should be done and complete by now). I'm building parts of the code based on my testing. Sometimes when I test something new (like adding a range in the datetime entity instead of just a value), I get an error when I try to set the values to the user since I haven't parsed the response right, and the new info I get makes me modify the DB structure at my end sometimes.
So, the bottom line, is there a complete reference that I can implement a complete client in my web app (my web app is in Java by the way and I couldn't find a client library that handles the latest version of the API)? Again, the tool is AWESOME but the documentation is not enough, or maybe I'm missing something.
The document is not enough of course but I think its pretty straightforward. And from what I read there is response structure under "Return the meaning of a sentence".
It's response in JSON format. So you need to decode the response first.
Example Request:
$ curl -XGET 'https://api.wit.ai/message?v=20170307&q=how%20many%20people%20between%20Tuesday%20and%20Friday' \
-H 'Authorization: Bearer $TOKEN'
Example Response:
{
"msg_id": "387b8515-0c1d-42a9-aa80-e68b66b66c27",
"_text": "how many people between Tuesday and Friday",
"entities": {
"metric": [ {
"metadata": "{'code': 324}",
"value": "metric_visitor",
"confidence": 0.9231
} ],
"datetime": [ {
"value": {
"from": "2014-07-01T00:00:00.000-07:00",
"to": "2014-07-02T00:00:00.000-07:00"
},
"confidence": 1
}, {
"value": {
"from": "2014-07-04T00:00:00.000-07:00",
"to": "2014-07-05T00:00:00.000-07:00"
},
"confidence": 1
} ]
}
}
You can read more about response structure under Return the meaning of a sentence
please tell me how to get available maintenance windows by using a SoftLayer REST API.
I tried it in the following way, but it did not work.
curl -K support -d #Maintence.json -X POST https://api.softlayer.com/rest/v3/SoftLayer_Provisioning_Maintenance_Window/getMaintenceWindows
When executing the command, the following error message is displayed:
{"error":"End date must be a later date than begin
date.","code":"SoftLayer_Exception"}
The contents of the JSON file are described below:
{
"parameters":[
{
"beginDate": "2016-12-22T00:00",
"endDate": "2016-12-29T00:00",
"locationId": 138124,
"slotsNeeded" : 1
}]
}
The proper API to use here is SoftLayer_Provisioning_Maintenance_Window::getMaintenanceWindows() as opposed to the misspelled getMaintenceWindows
The API payload is still the same.
curl -K support -d #Maintence.json -X POST https://api.softlayer.com/rest/v3/SoftLayer_Provisioning_Maintenance_Window/getMaintenanceWindows
{
"parameters":[
"2016-12-22T00:00",
"2016-12-29T00:00",
138124,
1
]
}
When making API calls to the softlayer API, the parameters are not named, just listed in order that matches the documentation.
You just need to send the parameters (It's not necesary to define them in an object), so try with this json:
{
"parameters":[
"2016-12-22T00:00",
"2016-12-29T00:00",
138124,
1
]
}
References:
SoftLayer_Provisioning_Maintenance_Window::getMaintenceWindows
I am trying to create a ticket using the freshdesk api (https://freshdesk.com/api#create_ticket) in Postman.
I have used the following: https://companyname.freshdesk.com/helpdesk/tickets.json
{ "helpdesk_ticket":
{ "description": "Details about the issue..."
, "subject": "Support Needed..."
, "email": "tom#outerspace.com"
, "priority": 1
, "status": 2
}
, "cc_emails": "ram#freshdesk.com,diana#freshdesk.com"
}
I am getting following response only:
{
"logout": "success"
}
I have tried clearing my browser cache many times. But the issue remains the same. Please someone suggest.
This must be a bug at the time the question is raised.
Now the API has been updated and it works smoothly, your endpoint should be https://yoururl.freshdesk.com/api/v2/tickets with Authorization Token in the header
I am also getting the same issues But When
I create the ssl login and check from curl then it works for me.
TL;DR
In my current API, I've got two endpoints to handle the context:
GET /context/get
POST /context/set '{"id": "123"}'
What's the recommended way of having this global, id-less state accessible from RESTful API?
Please assume that the context concept can't be changed.
Background
Let's say I've got a user that is logged. He's by default assigned to a context that he can change.
After the context change, all the subsequent API calls will return different data, according to the context.
Example:
// Backend
Context = "Poland"
then
$ curl -X GET http://api.myapp.com/cities
will respond:
{
"cities": [{
"id": "1",
"name": Warszawa"
}, {
"id": "2",
"name": Wrocław"
}]
}
However, if you change the context:
// Backend
Context = "USA"
then, the same URL:
$ curl -X GET http://api.myapp.com/cities
should return the different set of data:
{
"cities": [{
"id": "3",
"name": New York City"
}, {
"id": "4",
"name": Boston"
}]
}
Question
As the context is just a global state on the backend side, it doesn't have an id. It doesn't belong to any collection either. Still, I want it to be accessible in the API. There are three possible solutions I see:
Solution #1 - existing
Set a context
$ curl -X POST http://api.myapp.com/context/set '{"id": "123"}'
Get a context
$ curl -X GET http://api.myapp.com/context/get
This one doesn't really feel like a RESTful API and still, on the frontend side, I have to mock the id (using ember-data). And the resource name is singular instead of plural.
Solution #2 - mocking the id
Set a context
$ curl -X POST http://api.myapp.com/context/1 '{"contextId": "123"}'
Get a context
$ curl -X GET http://api.myapp.com/context/1
Here I mock the id to always equal to one but I feel that it's super hacky and certainly not self-explanatory... Moreover, I've got a name conflict: id vs contextId. And the resource name is singular instead of plural.
Solution #3 - actions
Set a context
$ curl -X POST http://api.myapp.com/context/actions/set '{"id": "123"}'
Get a context
$ curl -X GET http://api.myapp.com/context/actions/get
This is very similar to the first one but using actions that could be a part of my whole API design (taken from e.g. gocardless. Still, I'll have a problem how to model it on the frontend side nicely. And the resource name is singular instead of plural again.
Is there any #4 option? How should I address this problem?
Thanks!
Your three solutions are RPC, not REST. Not only they are not stateless, but setting a resource to some other resource by setting an id is very RCP'ish.
A RESTful solution, if you really want to go that way, is to set the context in a header. The client should send a header like X-ContextId or something like that, and you determine the request context you need from that.
However, don't worry too much about being RESTful if that's not what your application requires. I recommend reading the answer here: SOAP vs REST (differences)
What's the recommended way of having this global, id-less state
accessible from RESTful API?
A RESTful API is by definition stateless, no client context should be stored on the server between requests.
If you want your API to be RESTful, you'll have to pass this id with each request.