Gointerpay Checkout API Guide Technical Specification

Total Page:16

File Type:pdf, Size:1020Kb

Gointerpay Checkout API Guide Technical Specification GoInterpay Checkout API Guide Technical Specification Gointerpay Checkout API Specification v2 Revision 018 February 2017 gointerpay.com docs.gointerpay.net Questions and Comments: [email protected] Copyright 2014-2016 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. Table of Contents Table of Contents Changes From Revision 017 Notifications Order Notification Structure Contract Notification Structure Common Structures POST Request Error Consumer Consignee Card Details Action Return from Redirect Checkout API Requests fingerprint badge localize getRates getPaymentMethods create checkout openContract modify authorize capture cancel refund query Copyright 2014-2017 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. 1 Changes From Revision 017 Context Notes checkout, localize Clarified precision of ConsumerPrice. ​ ​ ​ getRates, localize Added Rates array for non-guaranteed market rates. ​ ​ authorize Added DeviceFingerprint, ViaAgent, OpenContract, and ContractId. ​ ​ ​ checkout Simplified shipping structure. create Added to create the order in GoInterpay separately from submitting payment details. openContract Added to simplify creation of contracts not related to an initial purchase. badge Added for access to required location declaration data on checkout pages. https://docs.gointerpay.net/display/PUB/Location+Declaration Copyright 2014-2017 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. 2 Notifications For a list of notifications and order states please refer to the States & Events page at https://docs.gointerpay.net/display/PUB/States+and+Events. ​ Notifications are sent via HTTP POST to a merchant-specified URL. The content of the HTTP POST is signed JSON which must be validated against the signature as follows: 1. Compute the SHA-256 HMAC value of the JSON entity using the shared secret; 2. Base-64 encode the result, and compare this to the specified Signature header. GoInterpay considers a notification delivered when it receives an HTTP 200 OK response. Notifications are re-sent until an HTTP 200 OK response is received. The HTTP Date header specifies the date and time the notification was generated. If a notification is received out of order or is unknown, the merchant should still produce an HTTP 200 OK but ignore the notification. Order Notification Structure Field Type Required Notes OrderId uuid Yes The GoInterpay order identifier returned in the checkout ​ response, identifying the order for the notification. ReferenceId string No The reference ID passed in in the original checkout request. ​ ​ UnderReview boolean Yes Set to true if a fraud review is in progress for the order. ​ ​ Payment cannot be processed until the review has been completed. Note that this is only applicable if the order has not failed or been cancelled. OrderState string Yes See documentation on Order States above. Refunds array No An array of refund data for refunds associated with the order. RefundId uuid Yes The external uuid of the refund assigned by GoInterpay. ReferenceId string Yes The reference id passed in by the merchant in the refund ​ request. State string Yes See documentation on Refund States above. Contract Notification Structure Field Type Required Notes ContractId uuid Yes The GoInterpay contract identifier returned in the openContract response. ​ ReferenceId string No The reference ID passed in in the original openContract ​ request. ContractState string Yes See documentation on Contract States above. Copyright 2014-2017 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. 3 Common Structures The following structures are used in many requests in the API. POST Request Error If there was an error when processing a POST request this is the error structure returned. Field Type Required Notes Code string Yes A request-specific error code, described in the Error Codes section for the specific request. Message string No A short description of the error. Consumer A Consumer is the person paying for an order and is sometimes referred to as a the billing contact. This information must match the address on file for the payment method used. Field Type Required Notes Name string Yes The consumer’s full name. Company string No Email string Yes Phone string Maybe Ideally specified using E.164 formatting, but this is not enforced. This is required for some payment methods and/or countries. Address string Yes The consumer’s street address. City string Yes The city associated with the consumer’s address. Region string Maybe The ISO-3166-2 subdivision code for the region (state, province, etc.) associated with the consumer’s address, not including the country code or dash. (eg NS, not CA-NS). This ​ ​ ​ ​ field may be omitted if there are no states/regions in the specified country. PostalCode string Maybe The postal code associated with the consumer’s address. This field may be omitted if there are no postal codes in the specified country. Country char(2) Yes The upper-case ISO 3166 alpha-2 country code associated with the consumer’s address. NationalIdentifier string Maybe The country-specific unique identifier of the consumer, without punctuation. It is required to be present for the consumer used for some payment methods and/or countries. In cases where this is required, this is commonly related to taxes. Examples are SSN for the United States, SIN for Canada and CPF for Brazil. Note that if a Company is specified, this is the identifier of the company if applicable, for example the CPNJ in Brazil. Copyright 2014-2017 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. 4 BirthDate string Maybe Required for some payment methods and/or countries. Must be specified as YYYY-MM-DD. ​ ​ MerchantProfileId string No The merchant’s identifier for the consumer’s profile. If submitted, this will link the consumer’s orders within GoInterpay for use in fraud analysis. IpAddress string Maybe If the request does not originate from the consumer’s browser and ViaAgent is false, the IP address of the consumer must ​ ​ be specified either here or in a subsequent authorize or modify ​ ​ ​ request. Consignee A consignee is the person receiving an order. This is sometimes referred to as the shipping contact. Field Type Required Notes Name string Yes The consignee’s full name. Company string No Email string No Phone string No Ideally specified using E.164 formatting, but this is not enforced. Address string Yes The consignee’s street address. City string Yes The city associated with the consignee’s address. Region string Maybe The ISO-3166-2 subdivision code for the region (state, province, etc.) associated with the consumer’s address, not including the country code or dash. (eg NS, not CA-NS). This ​ ​ ​ ​ field may be omitted if there are no states/regions in the specified country. PostalCode string Maybe The postal code associated with the consignee’s address. This field may be omitted if there are no postal codes in the specified country. Country char(2) Yes The upper-case ISO 3166 alpha-2 country code associated with the consignee’s address. Card Details If the merchant adheres to the requirements of PCI DSS SAQ-A-EP1, card details may be added to the ​ checkout, authorize, and/or openContract request in the card query string parameter, separate from the ​ ​ ​ ​ ​ ​ ​ main request body. Consequently, the card details are not included in the signature calculation. Field Type Required Notes Number string Yes The card number, without punctuation or whitespace. Name string Yes The name of the cardholder as it appears on the card. 1 https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf ​ Copyright 2014-2017 GoInterpay, Inc. All Rights Reserved. Proprietary & Confidential. Shared with Merchant Clients. 5 Expiry object Yes The expiration date of the card. Year integer Yes The expiry year, unabbreviated (ex. 2020). Month integer Yes The expiry month. 2 VerificationCode string Yes The card verification code. Action If additional action must be table to proceed with a request, this object contains information about the required action. Field Type Required Notes Redirect URL No The consumer must be redirected to the URL specified to complete the request. TODO: note about Return? Display object No A freeform JSON object which, in the context of the specified request, gives the necessary information for a consumer to proceed. See the Display Parameters section. Return from Redirect After the consumer has interacted with the site specified in a Redirect URL, their browser is redirected to the ​ ​ Return URL specified in the original request. The response and signature query parameters are appended ​ ​ ​ ​ ​ to this URL. The response contains the following JSON-encoded data. Field Type Required Notes Error object Yes If present, the order could not be authorized due to an error. See POST Request Error ​ -or- OrderId uuid Yes The 36 character UUID which identifies the order in the GoInterpay system. ContractId uuid No The contract identifier, if the order is associated with a contract. UnderReview boolean No Set to true if a fraud review has been initiated for the order. ​ ​ Payment cannot be processed until the review has been completed. If not present, assume false. OrderState string Yes See documentation on Order States above. Captured boolean No An indication of the whether or not the payment has been captured and therefore completed.
Recommended publications
  • Sunspec Plant Information Exchange
    Document #: 12042 Status: DRAFT Version D6 SunSpec Plant Information Exchange SunSpec Alliance Interoperability Specification SunSpec Alliance Plant Extract Document Workgroup Brett Francis, Bob Fox, Ferdy Nagy, Paul Cobb, Michael Palmquist, Jose Gomez, Stephen Lapointe, John Nunneley, Terry Terasammal, Francisco Ancin, Beth McCanlies Draft 6 ABSTRACT The SunSpec Specification suite consists of the following documentation: - SunSpec Technology Overview - SunSpec Information Model Specifications - SunSpec Model Data Exchange - SunSpec Plant Information Exchange This is the Plant Information Exchange document. A Plant Information Exchange standard enables these functions: • A common monitoring extract format for asset analysis tools • A means to extract and send historic plant data between different monitoring systems • A way to report asset performance to financial partners, for plants managed by different monitoring systems Change History D-1: Initial (A) Draft – Brett Francis : 2012-May-23 D-1: B Draft – workgroup 2012-May-31 and 2012-June-7, Brett Francis : 2012-Jun-12 D-1: C Draft – Additional elements and grammar improvements – Brett Francis : 2012-Jun-13 D-1: D Draft – workgroup 2012-June-28 – plant, sunSpecMetadata and strings blocks D-1: E Draft – workgroup 2012-July-05 – intro update, participant block, enumerated types – Brett Francis : 2012-Jul-18 D-1: F Draft – John Nunneley input 2012-Aug-09 T-1: A – Promoted to TEST level 1.0 – John Nunneley 2012-Aug-09 T-1: B – General formatting, layout and grammar improvements – Brett Francis 2012-Sept-05 T-2:A – Incorporating feedback – 2012-MMM-dd V2-D1: Flesh out financial oversight use case and NREL requirements. 2013-Feb-14 V2-D2: Incorporate feedback.
    [Show full text]
  • OASIS AMQP Version 1.0
    OASIS AMQP Version 1.0 Committee Specification Draft 01 / Public Review Draft 01 21 February 2012 Specification URIs This version: http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-overview-v1.0-csprd01.xml (Authoritative) http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-overview-v1.0-csprd01.html http://docs.oasis-open.org/amqp/core/v1.0/csprd01/amqp-core-complete-v1.0-csprd01.pdf Previous version: N/A Latest version: http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-overview-v1.0.xml (Authoritative) http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-overview-v1.0.html http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-complete-v1.0.pdf Technical Committee: OASIS AMQP Technical Committee Chairs: Ram Jeyaraman ([email protected]), Microsoft Angus Telfer ([email protected]), INETCO Systems Editors: Robert Godfrey ([email protected]), JPMorgan Chase & Co. David Ingham ([email protected]), Microsoft Rafael Schloming ([email protected]), Red Hat Additional artifacts: This specification consists of the following documents: • Part 0: Overview - Overview of the AMQP specification [xml] [html] • Part 1: Types - AMQP type system and encoding [xml] [html] • Part 2: Transport - AMQP transport layer [xml] [html] • Part 3: Messaging - AMQP Messaging Layer [xml] [html] • Part 4: Transactions - AMQP Transactions Layer [xml] [html] • Part 5: Security - AMQP Security Layers [xml] [html] • XML Document Type Definition (DTD) Related work: This specification replaces or supersedes: • http://www.amqp.org/specification/1.0/amqp-org-download Abstract: The Advanced Message Queuing Protocol (AMQP) is an open internet protocol for business messaging.
    [Show full text]
  • The Ethics of Language Development
    Winter 2016 Covers 4 and 1_Fall 2015 Covers 1 and 4 11/17/16 1:20 PM Page 1 L Winter , 2016 I S T E N I N G This issue: / J o u r n a l o f C o m m u n i c a t i o n E t h i c s The Ethics of , R e l i g i o Language n , a n d Development C u l t u r e V o l . 5 1 Volume 51 Number 1 Winter 2016 Covers 2 and 3_Fall 2013 Covers 2 and 3 11/17/16 1:20 PM Page 1 Journal of Communication Ethics, Religion, and Culture Editor ........................Janie M. Harden Fritz, Duquesne University Production Editor ......Craig T. Maier, Duquesne University Assistant Editor...........Joshua D. Hill, Duquesne University Consulting Editors ....Mark McVann, F.S.C., Saint Mary’s College of California Marilyn Nissim-Sabat, Lewis University Thomas E. Wren, Loyola University Chicago Assistant Production Editors ......................Matthew Mancino, Duquesne University Joshua D. Hill, Duquesne University Justin N. Bonanno, Duquesne University u The views expressed in the articles in Listening/Journal of Communication Ethics, Religion, and Culture remain those of the authors. Their publication does not constitute an endorsement, explicit or otherwise, by the editors. u Listening is published three times a year, in Winter, Spring, and Fall. All correspondence (including subscriptions) should be sent to the Editor, Listening/Journal of Communication Ethics, Religion, and Culture , Depart ment of Communication & Rhetorical Studies, Duquesne University, 600 Forbes Avenue, Pittsburgh, PA, 15282. Tel: (412) 396- 6558.
    [Show full text]
  • Languages and GRIN-Global
    Languages and GRIN-Global Revision Date June 11, 2015 This guide explains how to modify GRIN-Global to include languages other than English in the Curator Tool. These directions can also be used to edit the default English headings and descriptions. Change notes pertaining to this document are summarized in the appendix. Review the Table of Contents which contains links to the document’s topics. gg_language_guide_2015jun03.doc Page | 1 Contents GRIN-Global and Languages ................................................................................................................. 3 Overview ......................................................................................................................................... 3 Language-related Database Items in GRIN-Global ............................................................................ 3 Adding a Language to GRIN-Global ...................................................................................................... 5 Overview ......................................................................................................................................... 5 Language-Friendly Column Headings ................................................................................................... 6 Overview ......................................................................................................................................... 6 Storing Language-Friendly Column Heading Names at Two Levels .................................................... 6 Using the
    [Show full text]
  • Working-With-Mediawiki-Yaron-Koren.Pdf
    Working with MediaWiki Yaron Koren 2 Working with MediaWiki by Yaron Koren Published by WikiWorks Press. Copyright ©2012 by Yaron Koren, except where otherwise noted. Chapter 17, “Semantic Forms”, includes significant content from the Semantic Forms homepage (https://www. mediawiki.org/wiki/Extension:Semantic_Forms), available under the Creative Commons BY-SA 3.0 license. All rights reserved. Library of Congress Control Number: 2012952489 ISBN: 978-0615720302 First edition, second printing: 2014 Ordering information for this book can be found at: http://workingwithmediawiki.com All printing of this book is handled by CreateSpace (https://createspace.com), a subsidiary of Amazon.com. Cover design by Grace Cheong (http://gracecheong.com). Contents 1 About MediaWiki 1 History of MediaWiki . 1 Community and support . 3 Available hosts . 4 2 Setting up MediaWiki 7 The MediaWiki environment . 7 Download . 7 Installing . 8 Setting the logo . 8 Changing the URL structure . 9 Updating MediaWiki . 9 3 Editing in MediaWiki 11 Tabs........................................................... 11 Creating and editing pages . 12 Page history . 14 Page diffs . 15 Undoing . 16 Blocking and rollbacks . 17 Deleting revisions . 17 Moving pages . 18 Deleting pages . 19 Edit conflicts . 20 4 MediaWiki syntax 21 Wikitext . 21 Interwiki links . 26 Including HTML . 26 Templates . 27 3 4 Contents Parser and tag functions . 30 Variables . 33 Behavior switches . 33 5 Content organization 35 Categories . 35 Namespaces . 38 Redirects . 41 Subpages and super-pages . 42 Special pages . 43 6 Communication 45 Talk pages . 45 LiquidThreads . 47 Echo & Flow . 48 Handling reader comments . 48 Chat........................................................... 49 Emailing users . 49 7 Images and files 51 Uploading . 51 Displaying images . 55 Image galleries .
    [Show full text]
  • Prismtoken Thrift API 2019-01-16
    Tel: +27 11 343 2000 | Fax: +27 11 442 5908 | Email: [email protected] Address: President Place, Johannesburg, South Africa PrismToken Thrift API 2019-01-16 Document number: PR-D2-1009 Rev 1.0.1 Release date: 2019-01-16 Prepared by: TrevorD Copyright: © 2019 Prism Payment Technologies Synopsis: Specifies the Application Programming Interface (API) for PrismToken. Company Confidential The information in this document is intended only for the person or the entity to which it is addressed and may contain confidential and/or privileged material. Any views, recreation, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is prohibited. Disclaimer Prism Payment Technologies makes no representations or warranties whether expressed or implied by or with respect to anything in this document, and shall not be liable for any implied warranties of merchantability or fitness for a particular purpose or for any indirect, special or consequential damages. Prism Payment Technologies (Pty) Ltd | Reg No. 1990/005062/07 Directors: H.G. Kotzé, N. Pillay, A.M.R. Smith (British)| Company Secretary: C.W. van Straaten www.prism.co.za PrismToken Thrift API (PR-D2-1009 Rev 1.0.1)| Page 2 Contents 1 Introduction ............................................................................... 4 1.1 PrismToken overview ............................................................................................................... 4 1.2 Thrift overview .........................................................................................................................
    [Show full text]
  • April/May 2006 U.S
    Language | Technology | Business Industry Focus: Mobile Applications Embedded multilingual mobile applications Mobile applications for the Arabic market Chinese input on mobile devices Multilingual handwriting recognition technology Search engine marketing in multiple languages Open source: a model for innovation April/May 2006 U.S. $7.95 Canada $9.95 Getting Started Guide: Content Management 01 Cover #79 LW331-7.indd 1 4/10/06 8:02:59 AM 02-03 ads.indd 2 4/10/06 7:38:35 AM 0ODFVQPOBUJNFy -BOHVBHFTPGUXBSFXBTTMPXBOEEJTDPOOFDUFE 1FPQMFIBEUPQBZZFBSBGUFSZFBSGPSPMEUFDIOPMPHZ 5IFO-JPOCSJEHFPQFOFE'SFFXBZ /PX5.T HMPTTBSJFT BOESFQPSUTBSFBDDFTTFE UISPVHIUIF8FC"OEDMJFOUT 1.T BOEUSBOTMBUPST DPMMBCPSBUFJOTUBOUMZ 8IFSFXJMM'SFFXBZUBLFZPV 'BTU $POOFDUFE 'SFF XXX(FU0O5IF'SFFXBZDPN LB ad MLC free 31306 indd 1 3/17/06 1:19 PM 02-03 ads.indd 3 4/10/06 7:38:49 AM MultiLingual #79 Volume 17 Issue 3 April/May 2006 Editor-in-Chief, Publisher: Donna Parrish Managing Editor: Laurel Wagers IN THE GLOBAL MARKETPLACE, Translation Dept. Editor: Jim Healey Copy Editor: Cecilia Spence News: Kendra Gray, Becky Bennett Illustrator: Doug Jones Production: Sandy Compton Webmaster: Aric Spence Assistant: Shannon Abromeit Advertising Director: Jennifer Del Carlo Advertising: Kevin Watson, Bonnie Merrell Editorial Board Jeff Allen, Henri Broekmate, Bill Hall, Andres Heuberger, Chris Langewis, Ken Lunde, John O’Conner, Mandy Pet, Reinhard Schäler Advertising [email protected] www.multilingual.com/advertising 208-263-8178 Subscriptions, back issues, customer service [email protected] www.multilingual.com/subscribe With business moving at lightning speed, you need Submissions, letters the expertise of a partner experienced at navigating the [email protected] evolving global landscape. Our three decades of quality- Editorial guidelines are available at focused, advanced solutions have resulted in long-standing www.multilingual.com/editorialWriter client relationships.
    [Show full text]
  • The Hyperxmp Package∗
    The hyperxmp package∗ Scott Pakin [email protected] March 10, 2012 Abstract hyperxmp makes it easy for an author to include xmp metadata in a pdf document produced by LATEX. hyperxmp integrates seamlessly with hyperref and requires virtually no modifications to a document that already specifies document metadata through hyperref's mechanisms. 1 Introduction Adobe Systems, Inc. has been promoting xmp [3]|eXtensible Metadata Platform|as a standard way to include metadata within a document. The idea behind xmp is that it is an xml-based description of various document attributes and is embedded as uncompressed, unencoded text within the document it de- scribes. By storing the metadata this way it is independent of the document's file format. That is, regardless of whether a document is in pdf, jpeg, html, or any other format, it is trivial for a program (or human) to locate, extract, and|using any standard xml parser|process the embedded xmp metadata. As of this writing there are few tools that actually do process xmp. However, it is easy to imagine future support existing in file browsers for displaying not only a document's filename but also its title, list of authors, description, and other metadata. This is too abstract! Give me an example. Consider a LATEX document with three authors: Jack Napier, Edward Nigma, and Harvey Dent. The generated pdf file will contain, among other information, the following stanza of xmp code embedded within it: <dc:creator> <rdf:Seq> <rdf:li>Jack Napier</rdf:li> <rdf:li>Edward Nigma</rdf:li> <rdf:li>Harvey Dent</rdf:li> ∗This document corresponds to hyperxmp v1.5, dated 2012/03/10.
    [Show full text]
  • A Scalable Framework for Integrated Social Data Mining
    james meneghello ASCALABLEFRAMEWORKFORINTEGRATED SOCIALDATAMINING ASCALABLEFRAMEWORKFORINTEGRATEDSOCIALDATA MINING james meneghello This thesis is presented for the degree of: Doctor of Philosophy (Ph.D) School of Engineering and Information Technology Murdoch University 2016 James Meneghello: A scalable framework for integrated social data mining, , © 2016 DECLARATION I declare that this thesis is my own account of my research and contains as its main content work which has not previously been submitted for a degree at any tertiary education institution. Perth, Western Australia, 2016 James Meneghello ABSTRACT Social Networking Sites (SNS) are ubiquitous within modern society, forming communications networks that span across cultural and geographical boundaries. The information posted to these sites provide useful insights into individuals, but can also provide a wealth of information that can be used for further analysis into the surrounding environment. Three main challenges limit the use of this information in applications: the quantity of data is often unmanageable, there is a significant amount of data unavailable for use due to a lack of generic interfaces for access, and there is difficulty in integrating multiple disparate social data sources. The overall aim of the research described in this thesis is to advance the field of data science and improve accessibility of social data in analytical applications, in both academic and commercial settings. This aim has been addressed with three primary contributions; new algorithms to efficiently locate and collect relevant social data, new methods of performing unsupervised data extraction from generic social sites, and the development and subsequent empirical evaluation of a framework to facilitate the collection, integration, storage and presentation of social data for use in applications.
    [Show full text]
  • Pomen in Obseg Oznak Za Jezikovne Različice V Okviru Informacijske
    1 • Pomen in obseg oznak za jezikovne različice 2010 v okviru informacijske tehnologije • 16 Han Steenwijk Najprej.so.predstavljena.različna.merila.in.obsegi.jezikovnih.kod,.ki.so.regi- strirane.pri.ISO.639-1,.639-2,.639-3.in.639-6..Potem.sta.predstavljena.RFC. ZAPISKI 5646.in.4647,.kar.naj.bi.razložilo,.kako.se.lahko.oblikujejo.pravilne.oznake. za.jezikovne.različice..Nazadnje.je.ponujen.povzetek.zadeve.o.vložitvi.pro- šnje.o.kodi.za.rezijanščino. Ključne besede:.informacijska.tehnologija,.mednarodni.standardi,.kode.za. jezikovne.različice,.rezijansko.narečje.slovenščine The meaning and scope of tags for linguistic varieties in information technology This.article.first.discusses.the.various.criteria.for.and.scopes.of.the.language. codes.registered.as.ISO.639-1,.639-2,.639-3,.and.639-6..It.then.introduces. RFC.5646.and.RFC.4647.in.order.to.explain.how.well-formed.language.tags. can.be.created..Finally,.the.case.of.applying.for.a.language.code.for.Resian. is.summarized. JEZIKOSLOVNI Key words: information.technology,.international.standards,.language.vari- ety.codes,.Slovenian.dialects,.Resian.dialect.of.Slovenian 1 Samostalniki, pojmi in krajšave Občno.ime.in.lastno.ime.se.nanašata.na.pojme,.ki.se.nanašajo.na.konkretne.in.ab- straktne.predmete.v.resničnem.svetu..Tako.jezik.poimenuje.te.predmete..Odnosi. med.predmeti,.naj.bodo.taksonomski,.hierarhični.ali.kateri.drugi,.so.vsebovani.v.teh. pojmih..Na.primer:.poimenovanje.rezijanščina.se.nanaša.na.jezikovno.različico,.ki. jo.srečujemo.v.resničnem.svetu,.in.prav.tako.se.poimenovanje.slovenščina.nanaša. na.jezikovno.različico,.ki.jo.srečujemo.v.resničnem.svetu..Odnosi.med.tema.dvema. jezikovnima.različicama.niso.neločljive.lastnosti.samih.samostalnikov.rezijanščina.
    [Show full text]
  • Gtts Documentation
    gTTS Documentation Pierre-Nick Durette Apr 28, 2018 Documentation 1 Installation 3 1.1 Command-line (gtts-cli)......................................3 1.1.1 gtts-cli..............................................3 1.1.2 Examples............................................4 1.1.3 Playing sound directly.....................................5 1.2 Module (gtts).............................................5 1.2.1 gTTS (gtts.gTTS)......................................5 1.2.2 Languages (gtts.lang)...................................6 1.2.3 Examples............................................7 1.2.4 Playing sound directly.....................................7 1.2.5 Logging.............................................7 1.3 Pre-processing and tokenizing......................................8 1.3.1 Definitions...........................................8 1.3.2 Pre-processing.........................................8 1.3.3 Tokenizing........................................... 10 1.3.4 gtts.tokenizer module reference (gtts.tokenizer).................... 11 1.4 License.................................................. 15 1.5 Contributing............................................... 15 1.5.1 Reporting Issues........................................ 15 1.5.2 Submitting Patches....................................... 15 1.5.3 Testing............................................. 16 1.6 Changelog................................................ 16 1.6.1 2.0.0 (2018-04-28)....................................... 16 1.6.2 1.2.2 (2017-08-15)......................................
    [Show full text]
  • Apple Maps Business Listings Integration Specifications Document Version 1.7.3B
    Apple Maps Business Listings Integration Specifications Document Version 1.7.3b Maps Content Provider 2016 | Apple Confidential Contents CONTENTS ................................................................................................................... 2 OVERVIEW ................................................................................................................... 3 BASE AND RICH ATTRIBUTES ........................................................................................ 4 Data Definition ................................................................................................................................................... 4 Data Format ..................................................................................................................................................... 15 PHOTOS AND REVIEWS .............................................................................................. 19 Data Definition ................................................................................................................................................ 19 Data Format ..................................................................................................................................................... 22 2016 | Apple Confidential Overview This document defines the set of attributes required to capture information about a business listing. Attributes have been classified as either "Base and Rich" or "Photos and Reviews". Base and Rich attributes describe a business, Photos and
    [Show full text]